A method for running Open Harmony applications on Android.

Abstract

The application provides a method for running OpenHarmony applications in an Android system, steps comprising: transplanting a JSUI framework and a package management subsystem of OpenHarmony to an Android system, and storing a ShellAPK to an Android device; a host end HDC tool calling an Android end HDCD daemon process to install a HAP based on a bm instruction; generating a mapping relationship of the HAP and the ShellAPK according to a rule, and persisting the mapping relationship; selecting a corresponding ShellAPK and installing and running the ShellAPK to provide an Android context environment; finding a program package name and a path of the OpenHarmony application to prepare for loading a JS file; loading content of the HAP; and carrying an ACE view on an AndroidView by using ace.so. In this way, the OpenHarmony application can run on the Android system.

Description

Technical Field

[0001] This invention relates to Android system application technology, and more particularly to a method for running Open Harmony applications in the Android system. Background Technology

[0002] Open Harmony is an open-source project incubated and operated by the OpenAtom Foundation, and managed by the OpenAtom Foundation's Open Harmony Project Group Working Committee. Harmony OS is a commercial version developed by Huawei based on the open-source project Open Harmony, targeting various smart devices across all scenarios.

[0003] Currently, Harmony applications can run on Android, but Open Harmony applications cannot. One reason for this is that Open Harmony applications do not have their own shell application package (stub), which prevents Android from providing them with a runtime environment and window environment.

[0004] Therefore, how to make Open Harmony applications run on the Android system has become an urgent problem for Android system developers. Summary of the Invention

[0005] Therefore, the main objective of this invention is to provide a method for running Open Harmony applications on the Android system, so that Open Harmony applications can run on the Android system.

[0006] To achieve the above objectives, according to one aspect of the present invention, a method for running an Open Harmony application in an Android system is provided, comprising the steps of: Step S100: Port the JS UI framework and package management subsystem from Open Harmony to the Android system, and store the Shell APK on the Android device; Step S200: The host-side HDC tool uses the USB protocol to call the Android-side HDCD daemon to call the BundleMgrService class based on the bm command to install HAP. Step S300 generates a mapping relationship between HAP and Shell APK according to the rules and persists the mapping relationship; uses the BundleMgrAdapter class to select the corresponding Shell APK according to the mapping relationship and installs it; Step S400 runs the Shell APK, providing the Android context environment based on ACE Application; locates the package name and path of the Open Harmony application to prepare for loading JS files; and uses AbilityShellActivity to load and display the HAP content. Step S500 uses ace.so to host the ACE view on an Android View, which includes: creating an AceAbility instance in AbilityShellActivity, and displaying the container AceContainer inside AceAbility.

[0007] In a possible preferred embodiment, step S100, storing the Shell APK on the Android device, includes: packaging the Shell APK into a system image file using a compilation script, and then storing it on the Android device.

[0008] In a possible preferred embodiment, step S300, the step of generating the mapping relationship, includes: When installing HAP, the status of the Shell APK is checked. If the Shell APK is in an unused state, it is installed; if the Shell APK is in a used state, it is installed in sequence until an unused Shell APK is detected. After installation, the key-value pair relationship between the Shell APK and HAP is recorded in the system properties, and the usage status of the Shell APK is updated to complete the generation of the mapping relationship, where K is the Package Name of the Shell APK and V is the Bundle Name of the HAP application.

[0009] In a possible preferred embodiment, the Shell APK uses a state update step including: The usage status of each Shell APK is encoded in binary, such as 1 representing installed and used, and 0 representing uninstalled and unused. When a Shell APK is installed, the binary encoded usage status is used as a flag bit with carry, and then the binary encoding of the current usage status and the binary encoding of the status value after bitwise operation are ORed to obtain the final status. When the Shell APK is uninstalled, the usage status of the binary code is used as an identifier bit in the carry mode, then the complement is taken, and the final status is obtained by AND operation between the binary code of the current usage status and the complement. The usage status of the Shell APK is saved via SettingsProvider.

[0010] To achieve the above objectives, according to another aspect of the present invention, a computer device is also provided, including a memory and a processor, the memory storing a computer program, wherein the processor executes the computer program to implement the steps of the method for running an Open Harmony application in the Android system as described in any of the above.

[0011] To achieve the above objectives, according to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the method for running an Open Harmony application in the Android system as described in any of the above.

[0012] The method for running Open Harmony applications in the Android system provided by this invention enables OpenHarmony applications to run on the Android system. In some implementations, since binary encoded values ​​are used to store the usage status of all Shell APKs (stubs) and to perform bitwise operations to update the usage status of Shell APKs (stubs), memory can be saved compared to using SettingsProvider, and bitwise operations make the program faster. Attached Figure Description

[0013] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram illustrating the concept of porting a JS UI framework to Android in the method of the present invention; Figure 2 This is a schematic diagram illustrating the structure of the Harmony application and the Open Harmon application in the method of the present invention, as well as the structural relationship between them; Figure 3 This is a schematic diagram illustrating the mapping relationship between the Open Harmony application and the Shell APK (stub) in the method of this invention; Figure 4 This is a schematic diagram illustrating the logic of installing HAP on an Android device via USB protocol using a PC-side HDC in the method of this invention. Figure 5 This is a logical diagram illustrating the selection and installation of Shell APKs (stubs) based on mapping relationships in the method of the present invention; Figure 6 This is a schematic diagram of the ACE framework structure in the method of the present invention; Figure 7This is a schematic diagram illustrating the logical structure of creating an AceAbility instance in AbilityShellActivity and displaying the AceContainer instance within the AceAbility instance in the method of this invention. Figure 8 This is a functional structure diagram of the computer device of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the technical solutions of the present invention, the specific technical solutions of the present invention will be clearly and completely described below in conjunction with embodiments, so as to help those skilled in the art further understand the present invention. Obviously, the embodiments described in this application are merely some embodiments of the present invention, and not all embodiments. It should be noted that, for those skilled in the art, the embodiments and features in the embodiments of this application can be combined with each other without departing from the concept of the present invention and without conflict. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the disclosure and protection scope of the present invention.

[0015] Furthermore, the terms "first," "second," "S1," "S2," etc., used in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those described herein. At the same time, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. Unless otherwise expressly specified and limited, the terms "set," "arranged," "installed," "connected," and "linked" should be interpreted broadly, for example, as a fixed connection, a detachable connection, or an integral connection; a mechanical connection or an electrical connection; a direct connection or an indirect connection through an intermediate medium; or a connection within two elements. Those skilled in the art can understand the specific meaning of the above terms in this case based on the specific circumstances and in conjunction with existing technology.

[0016] In this example, the shell application for Harmony OS is called a Shell APK (stub). Since the Open Harmony application does not have a shell application, Android cannot provide a runtime environment and window environment for its application.

[0017] Therefore, in order to solve this problem, such as Figures 1 to 7 As shown, this invention provides a method for running an Open Harmony application in an Android system, the steps of which include: Step S100: Port the JS UI framework and package management subsystem from Open Harmony to the Android system, and store the Shell APK on the Android device; Step S200: The host-side HDC tool uses the USB protocol to call the Android-side HDCD daemon to call the BundleMgrService class based on the bm command to install HAP. Step S300 generates a mapping relationship between HAP and Shell APK according to the rules and persists the mapping relationship; uses the BundleMgrAdapter class to select the corresponding Shell APK according to the mapping relationship and installs it; Step S400 runs the Shell APK, providing the Android context environment based on ACE Application; locates the package name and path of the Open Harmony application to prepare for loading JS files; and uses AbilityShellActivity to load and display the HAP content. Step S500 uses ace.so to host the ACE view on an Android View, which includes: creating an AceAbility instance in AbilityShellActivity, and displaying the container AceContainer inside AceAbility.

[0018] The concept of this invention is to port the JS UI framework and package management subsystem from OpenHarmony to the Android system, then add an Adapter to the zframework package, positioned as an Ace environment builder, including JS parsing capabilities, Ace Ability context, Ace container, Ace view, Ace page, etc., then establish a JNI pipeline to connect Java objects with corresponding objects and APIs in the Ace subsystem, and port two libraries of OHOS Ace (libace.z.so / libace_engine_qjs.z.so).

[0019] In this way, the Android system has the ability to use Open Harmony application base classes, container classes, canvas classes, and other UI, standard CSS animation capabilities, as well as package management capabilities.

[0020] Specifically, the JS UI framework is the OpenHarmony UI development framework, and the JS UI framework is called ACE, which stands for Ability Cross-platform Environment. It provides UI components such as base classes, container classes, and canvas classes, as well as standard CSS animation capabilities, and supports web-like programming paradigms.

[0021] A JavaScript UI framework consists of an application layer, a front-end framework layer, an engine layer, and a platform adaptation layer. The Application layer represents the FA application developed by the developer using the JS UI framework. Here, FA application specifically refers to JS FA application.

[0022] The Framework front-end framework layer mainly completes the parsing of front-end pages, and provides capabilities such as MVVM (Model-View-ViewModel) development mode, page routing mechanism and custom components.

[0023] The Engine layer primarily provides capabilities such as animation parsing, DOM (Document Object Model) tree construction, layout calculation, rendering command construction and drawing, and event management.

[0024] The Porting Layer primarily abstracts the platform layer, providing abstract interfaces that can be connected to the system platform. Examples include event integration, rendering pipeline integration, and system lifecycle integration.

[0025] The solution for porting the JS UI framework is as follows: I. Self-implemented Java JS UI component The Java JS UI Adapter is the JS UI framework component, primarily consisting of Java code. It includes AceAbility, AceContainer, and AceNativeView. Specifically: 1. AceContainer calls OHOS's AceContainer via JNI; 2. AceNativeView calls OHOS's AceView via JNI. The Java JS UI Adapter compiles the target file zframework.aar. Its function is to provide functional interfaces and a runtime environment for application display, calling OHOS services via JNI.

[0026] II. Porting OHOS's JS UI source code to Android The OHOS source code compilation target files are libace.z.so and libace_engine_qjs.z.so. Examples of OHOS source code: Native Adapter: ├──" / / foundation / ace / ace_engine / adapter" Framework: ├──" / / third_party / jsframework" └──" / / third_party / quickjs Bridge: ├──" / / foundation / ace / ace_engine / frameworks / bridge" Porting Layer: ├──" / / foundation / ace / ace_engine / adapter" Flutter: ├──" / / third_party / flutter The package management subsystem is responsible for managing application installation packages, providing capabilities such as package information query, installation, update, uninstallation, and package information storage. It includes: The package management interface module is used for: 1. providing external interfaces for installation, update, uninstallation, and notification; 2. providing external interfaces for querying package / component information / permission information; 3. providing external interfaces for querying application permissions; and 4. providing external interfaces for clearing data.

[0027] The scanning module is used for: 1. Scanning pre-installed applications; 2. Scanning installed third-party applications; 3. Parsing package configuration files; The security management module is used for: 1. Signature verification during installation; 2. Granting permissions requested by the application during installation; 3. Verifying permissions during application runtime. The DBMS module is used to obtain capability information for a specified device. The installation management module is used for installation, update, and uninstallation logic processing and result notification. The package information management module is used for storing and synchronizing package information and component information. The device status monitoring module is used to monitor the online / offline status of devices. The Installed module is used by privileged processes for: 1. Creating and deleting directories; 2. Creating and deleting files; 3. Managing sandbox uid / gid values ​​in device directories. DFX stands for Package Management and Monitoring Tool.

[0028] The solution for porting the package management subsystem is as follows: I. Self-implemented Java Bundle Manager Adapter: The Java Bundle Manager Adapter is part of the bundle management subsystem framework, primarily consisting of Java code. It includes IPCSkeleton, SysAbilityManager, BundleManager, and BundleInstaller.

[0029] in: 1. IPCSkeleton calls OHOS's IPCSkeleton through a remote proxy. 2. SysAbilityManage calls OHOS's SysAbilityManage through a remote proxy. 3. BundleManager calls OHOS's BundleMgrService through a remote proxy. 4. BundleInstaller calls OHOS's BundleInstallerHost through a remote proxy. Java Bundle Manager Adapter compilation target file zframework.aar Its function is to provide a service interface for application installation and management, and to call OHOS services through a remote proxy.

[0030] II. Porting OHOS's BMS and BM source code to Android OHOS source code section: The target file libbms.so is compiled from the OHOS source code.

[0031] bm ├──" / / foundation / aafwk / standard / interfaces / innerkits / want:want", : The external interface for information carriers interacting between Abilities in the meta-capability subsystem. └── " / / foundation / aafwk / standard / services / abilitymgr:abilityms", :Code for the Meta-Capability Subsystem Ability Management Service Framework installs ├──" / / third_party / zlib:libz", : Provides a library of functions for data compression. └──" / / base / security / permission / interfaces / innerkits / permission_standard / permissionsdk:libpermissionsdk_standard", : Application permission management libbms ├──" / / third_party / zlib:libz", : Provides a library of functions for data compression. ├──" / / foundation / appexecfwk / standard / libs / libeventhandler:libeventhandler_target", ├──" / / base / security / appverify / interfaces / innerkits / appverify:libhapverify", : Application integrity verification ├──" / / base / security / permission / interfaces / innerkits / permission_standard / permissionsdk:libpermissionsdk_standard", : Application permission management ├──" / / foundation / aafwk / standard / interfaces / innerkits / base:base", : Some basic data types in HarmonyOS, such as Boolean, Array, String, Long, Integer... ├──" / / foundation / aafwk / standard / interfaces / innerkits / want:want", : The external interface for information carriers that interact between Abilities. ├──" / / foundation / distributeddatamgr / distributeddatamgr / interfaces / innerkits / distributeddata:distributeddata_inner", : Native interface for distributed data services ├──" / / foundation / distributedschedule / safwk / interfaces / innerkits / safwk:system_ability_fwk", : External interfaces of safwk components, such as SystemAbility ├──"ces_standard:cesfwk_core", : Internal implementation of the native interface of the event notification subsystem component, such as CommonEvent ├──"ces_standard:cesfwk_innerkits", : Native interface definition for the event notification subsystem component, such as └──CommonEventData, PublishCommonEvent Public dependencies ├──"hiviewdfx_hilog_native:libhilog", ├──"ipc:ipc_core", ├──" / / foundation / distributedschedule / samgr / interfaces / innerkits / samgr_proxy:samgr_proxy", : External interfaces of the samgr component, such as SystemAbilityManagerClient ├──" / / foundation / appexecfwk / standard / common:libappexecfwk_common",: User program framework subsystem logging components and time consumption statistics related components. ├──" / / foundation / appexecfwk / standard / interfaces / innerkits / appexecfwk_core:appexecfwk_core", :IBundleInstaller, BundleMgrProxy, BundleInstallerProxy ├──" / / foundation / appexecfwk / standard / interfaces / innerkits / appexecfwk_base:appexecfwk_base", : InstallFlag, InstallLocation, InstallParam └──" / / utils / native / base:utils", : C++ Common Basic Library After completing the above porting, pre-store the Shell APK (stubs) on the Android device. For example, the ShellApks.zip archive contains several Shell APKs (stubs). Use a compilation script to package ShellApks.zip into a system image file. Then, burn the image onto an Android device, such as an Android phone, thus pre-storing the Shell APK (stubs) in the Android system.

[0032] Next, at runtime, the Shell APK (Android application package) (stub) is launched first. The Shell APK (stub) links to the corresponding HAP (OpenHarmonyOS ability package) resources according to the mapping relationship. The application package Shell APK (stub) provides the runtime and windowing environment for Open Harmony applications.

[0033] For example, users install HAP using the HDC tool.

[0034] The HDC (HarmonyOS Device Connector) is a command-line tool provided by Harmony OS for developers to debug, allowing them to interact with real devices or simulators on Windows / Linux / Mac systems.

[0035] To install the Open HarmonyOS package, use the following command format: hdc app install package The parameter package: Open HarmonyOS application installation package.

[0036] Usage instructions, taking the installation of the com.example.hello package as an example: hdc app install com.example.hello The PC-based HDC calls the Android device's HDCD daemon process via the USB protocol. The HDCD daemon process then calls the `bm` command, such as... Figure 4 As shown, the bm command calls the BundleMgrService class to install HAP.

[0037] After that, as Figure 3 As shown, the mapping relationship between HAP and Shell APK is generated according to the rules, and the mapping relationship is persisted. After recording the KV key-value pair relationship (K: Shell APK (stub) Package Name V: HAP application Bundle Name) between Shell APK (stub) and HAP into the system properties, the corresponding Shell APK is selected and installed based on the mapping relationship by the BundleMgrAdapter class, thus completing the Shell APK installation program.

[0038] To accelerate program execution, the rule for generating the above mapping relationship in this example is as follows: Assume the Shell APK (stub) name is shellapplication + identifier, where the identifier is Arabic numerals starting from 0. The Shell APK (stub) names are shellapplication0.apk, shellapplication1.apk, ..., shellapplication11.apk.

[0039] Assume the Open Harmony application name is hapapplication + identifier, where the identifier is Arabic numerals starting from 0. The Shell APK (stub) names are hapapplication0.hap, hapapplication1.hap, ..., hapapplication11.hap.

[0040] When installing hapapplication0.hap, check the status of shellapplication0.apk: When the application is not in use, shellapplication0.apk will be used for installation first. After successful installation: (1) Record the KV key-value pairs of shellapplication0 and hapapplication0 in the system properties, where K: Package Name of shellapplication0 and V: Bundle Name of hapapplication0.

[0041] (2) Update the usage status of shellapplication0.apk, record the KV key-value pair relationship between shellapplication0 and shellapplication0 usage status value in the system properties, where K: Package Name of shellapplication0 + "state" V: usage status value of shellapplication0.

[0042] When the shell APK is in use, check its usage status until an unused shell APK (stub) is found and installed successfully: (1) Record the KV key-value pairs of Shell APK (stub) and HAP in the system properties.

[0043] (2) Update the usage status of Shell APK (stub).

[0044] This example also proposes a Shell APK (stub) usage state update algorithm as follows: Assume the Shell APK (stub) name is shellapplication + identifier, where the identifier is Arabic numerals starting from 0. The Shell APK (stub) names are shellapplication0.apk, shellapplication1.apk, ..., shellapplication11.apk.

[0045] Suppose we need to record the usage and unused status of 12 stakes, where 1 represents installed and used, and 0 represents uninstalled and unused.

[0046] The binary number on the right represents the initial state of the 12 stubs: 0000 0000 0000. When the Shell APK is installed, the state is 0000 0000 0001. The state is then left-shifted by the flag bit and then ORed with the current state and the bitwise operation result to obtain the final state.

[0047] When the Shell APK is uninstalled, the state is 0000 0000 0001, shifted left by the flag bit, and then the complement is taken. The final state is obtained by performing a bitwise AND operation between the current state and the complement.

[0048] Therefore, compared to the usual practice of storing the Shell APK (stub) usage state through SettingsProvider, this algorithm has the advantage of using a string of binary values ​​to store the usage state of all Shell APK (stubs), and using bitwise operations to update the Shell APK (stub) usage state, which saves memory compared to using SettingsProvider, while bitwise operations also make the program faster.

[0049] Once the Shell APK is installed, you can run and load the application. When the Shell APK runs, it will provide the Android context environment based on ACEApplication. Simultaneously, it will use previously saved system properties to locate the package name and path of the OpenHarmony application, preparing for loading the JS files. AbilityShellActivity then loads and displays the HAP content.

[0050] Next, the display issue needs to be resolved, as shown in this example. Figures 6 to 7 As shown, using ace.so to host an ACE view on an Android View includes: creating an AceAbility instance in AbilityShellActivity, and then displaying the container AceContainer inside AceAbility. This completes the display of the Open Harmony application on an Android View.

[0051] AceContainer provides various UI rendering capabilities and serves as the overall management class, offering lifecycle and function scheduling interfaces. Internally, it is divided into many sub-modules, such as: Frontend: The execution environment for frontend code, either JS or JSON. This abstraction may also support other script engines.

[0052] TaskExecutor: A single-threaded task manager, similar to TaskRunner in other rendering engines.

[0053] AssetManager: A resource manager that can be used to load resources such as JS code, images, and fonts. It should also have caching capabilities.

[0054] PipelineContext: The class that manages the rendering pipeline, listening for vsync callbacks to refresh the layout, drawing, and rendering of internal dirty nodes.

[0055] AceView: The root node of the rendered UI, which can be pasted into the outer container.

[0056] PlatformResRegister: This is where platform resources are registered and managed, as well as some communication interfaces. Same-layer rendering functionality can be implemented here.

[0057] It's worth noting that in traditional Harmony systems, the Shell APK (stubs), classes.dex, and assets folders are all packaged into a single HAP file. Furthermore, the package name of the Shell APK (stubs) must match the package name of the Java files inside classes.dex and the directory name where the assets files are located. Therefore, the path coupling in the system is too high.

[0058] Compared to the Harmony system, the present invention provides a solution in which the Shell APK (stub) package name and assets are packaged separately, and the classes.dex file is removed to reduce coupling. In addition, the Shell APK package name and assets file path names do not need to be the same, and the Open Harmony application can be run dynamically using the Shell APK, thus having significant advantages.

[0059] On the other hand, corresponding to the above embodiments, such as Figure 8 As shown, the present invention also provides a computer device including a memory and a processor, the memory storing a computer program, wherein the processor executes the computer program to implement the steps of the method for running an Open Harmony application in the Android system as described in any of the above embodiments.

[0060] On the other hand, corresponding to the above embodiments, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method for running an Open Harmony application in the Android system as described in any of the above embodiments.

[0061] In summary, the method for running Open Harmony applications on the Android system provided by this invention enables Open Harmony applications to run on the Android system. Furthermore, in some implementations, since binary encoded values ​​are used to store the usage status of all Shell APKs (stubs) and to perform bitwise operations to update the usage status of Shell APKs (stubs), memory can be saved compared to using SettingsProvider, and bitwise operations also make the program faster.

[0062] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The present invention is limited only by the claims and their full scope and equivalents. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the protection scope of the invention.

[0063] Those skilled in the art will understand that, besides implementing the system, apparatus, and their modules provided by this invention in purely computer-readable program code, the same program can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system, apparatus, and their modules provided by this invention can be considered a hardware component, and the modules included therein for implementing various programs can also be considered structures within the hardware component; alternatively, modules for implementing various functions can be considered both software programs implementing the method and structures within the hardware component.

[0064] Furthermore, all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a microcontroller, chip, or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0065] Furthermore, various different implementations of the present invention can be combined arbitrarily, as long as they do not violate the spirit of the present invention, they should also be regarded as the content disclosed in the present invention.

Claims

1. A method for running an Open Harmony application on an Android system, characterized by the following steps: include: Step S100: Port the JS UI framework and package management subsystem in Open Harmony to the Android system, and store ShellAPK on the Android device; Step S200: The host-side HDC tool uses the USB protocol to call the Android-side HDCD daemon to call the BundleMgrService class based on the bm command to install HAP. Step S300 generates a mapping relationship between HAP and Shell APK according to the rules and persists the mapping relationship; uses the BundleMgrAdapter class to select the corresponding Shell APK according to the mapping relationship and installs it; Step S400 runs the Shell APK, which provides the Android context environment based on ACE Application; it locates the package name and path of the OpenHarmony application to prepare for loading the JS file. The AbilityShellActivity is used to load and display HAP content; Step S500 uses ace.so to host the ACE view on an Android View, including: creating an AceAbility instance in AbilityShellActivity, and displaying the container AceContainer inside the AceAbility instance; In step S300, the mapping relationship generation step includes: when installing HAP, checking the status of Shell APK; if the Shell APK is in an unused state, installing it; if the Shell APK is in a used state, installing it sequentially until an unused Shell APK is detected; after installation, recording the KV key-value pair relationship between Shell APK and HAP in the system attributes, and updating the usage status of Shell APK to complete the mapping relationship generation, where K is the Package Name of Shell APK and V is the HAP application Bundle Name.

2. The method for running an Open Harmony application in an Android system according to claim 1, characterized in that, In step S100, the step of storing the Shell APK on the Android device includes: packaging the Shell APK into a system image file using a compilation script, and then storing it on the Android device.

3. The method for running an Open Harmony application in an Android system according to claim 1, characterized in that, The Shell APK usage status update steps include: The usage status of each Shell APK is encoded in binary. When a Shell APK is installed, the usage status encoded in binary is used as an identifier bit with carry. Then, the binary encoding of the current usage status and the binary encoding of the status value after bitwise operation are ORed to obtain the final status. When the Shell APK is uninstalled, the usage status of the binary code is used as an identifier bit in the carry mode, then the complement is taken, and the final status is obtained by AND operation between the binary code of the current usage status and the complement. The usage status of the Shell APK is saved via SettingsProvider.

4. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 3.

5. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 3.

Images