Mobile application migration method, system, terminal and storage medium based on state transition diagram and dynamic verification

Abstract

The application relates to the field of application migration technology and discloses a mobile application migration method and system based on a state transition graph and dynamic verification, a terminal and a storage medium.The method comprises the following steps: obtaining running information of an Android application to construct a state transition graph; modeling an Android page based on the state transition graph to obtain a Harmony page; compiling the Harmony page to obtain an initial Harmony application program package; and performing multiple repairs on the initial Harmony application program package to obtain a target Harmony application program package which can be migrated.The application can generate a complete, compilable, installable and runnable Harmony application in the case that the original application source code is absent, can better preserve the interface appearance and interaction logic of the original application, can reduce the page relationship inference error and runtime interaction exception, and can effectively improve the reliability and actual availability of the cross-system application migration result.

Description

Technical Field

[0001] This invention relates to the field of application migration technology, and in particular to a mobile application migration method, system, terminal, and computer-readable storage medium based on state transition diagrams and dynamic verification. Background Technology

[0002] Cross-platform migration of mobile applications is a long-standing engineering problem in the field of software engineering. Different mobile operating systems typically employ different development languages, interface frameworks, routing mechanisms, build toolchains, and application package formats. When a new mobile ecosystem emerges or enterprises need to quickly extend the same business to multiple platforms, developers often need to repeatedly implement interface layouts, interaction logic, page navigation, resource references, and system API (Application Programming Interface) calls. This is costly, time-consuming, and can easily introduce inconsistent user experiences.

[0003] However, existing source code-based cross-platform migration technologies rely on source code such as layout files, which are insufficient in dealing with cross-file and cross-component issues and lack complete multi-page interaction modeling. On the other hand, page transition diagrams generated by UI (User Interface) code generation technologies based on screenshots or visual input are unreliable, page modeling is overly simplified, and there is a lack of runtime verification.

[0004] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0005] The main objective of this invention is to provide a mobile application migration method, system, terminal, and computer-readable storage medium based on state transition diagrams and dynamic verification, aiming to solve the problem in the prior art that it is difficult to accurately restore the interface structure, page relationships, and interaction logic of the original application when the original application source code is missing.

[0006] To achieve the above objectives, the present invention provides a mobile application migration method based on state transition diagrams and dynamic verification, the mobile application migration method based on state transition diagrams and dynamic verification comprising the following steps: When running an Android application, various runtime information of the Android application is obtained, and a state transition diagram of the Android application is constructed based on all the runtime information. The action sequence is obtained by traversing the edges of the state transition graph. Based on the action sequence, all Android pages in the state transition graph are modeled to obtain the corresponding HarmonyOS pages. After compiling all the HarmonyOS pages, an initial HarmonyOS application package is obtained. The initial HarmonyOS application package is installed on the HarmonyOS device for dynamic verification. If the verification fails, multiple HarmonyOS pages are modified until the verification is successful, resulting in an intermediate HarmonyOS application package. When running the intermediate HarmonyOS application package, all HarmonyOS pages are monitored, and multiple HarmonyOS pages are optimized according to the corresponding Android pages to obtain the target HarmonyOS application package.

[0007] Optionally, in the mobile application migration method based on state transition diagram and dynamic verification, the runtime information includes: Android page and execution action; The step of obtaining various runtime information of the Android application while it is running, and constructing a state transition diagram of the Android application based on all the runtime information, specifically includes: Install the Android application package and run the corresponding Android application. During runtime, collect all Android pages and all execution actions of the Android application. Each Android page is defined as a corresponding node, and the execution action between any two Android pages is defined as a corresponding edge; For each edge, each edge and the two nodes connecting the edge are defined as a directed edge. The state transition graph of the Android application is constructed based on all the directed edges and all the nodes.

[0008] Optionally, the mobile application migration method based on state transition graph and dynamic verification, wherein the step of performing edge traversal on the state transition graph to obtain an action sequence, and modeling all Android pages in the state transition graph according to the action sequence to obtain the corresponding HarmonyOS page, specifically includes: Starting from the home screen of the Android application, all directed edges in the state transition graph are traversed to generate an action sequence for running the Android application. Based on the action sequence, determine whether there is a HarmonyOS page corresponding to the Android page in the HarmonyOS resource library, and determine the processing method for obtaining the HarmonyOS page based on the determination result. Each of the aforementioned processing methods is input into the code generation agent, which outputs the HarmonyOS page corresponding to each of the aforementioned Android pages.

[0009] Optionally, the mobile application migration method based on state transition diagrams and dynamic verification, wherein determining whether a HarmonyOS page corresponding to the Android page exists in the HarmonyOS resource library according to the action sequence, and determining the processing method for each Android page based on the determination result, specifically includes: Based on the action sequence, determine the Android page for each directed edge and the Android state transition relationship between the two Android pages; For each of the directed edges, determine in the HarmonyOS resource library whether there are multiple initial HarmonyOS pages and HarmonyOS state transition relationships corresponding to all the Android pages and the Android state transition relationships; If they exist, then all corresponding HarmonyOS pages will be obtained by modifying all the initial HarmonyOS pages. If it does not exist, then all corresponding HarmonyOS pages will be obtained by constructing new pages.

[0010] Optionally, the mobile application migration method based on state transition diagrams and dynamic verification, wherein inputting each processing method into a code generation agent and outputting the HarmonyOS page corresponding to each Android page specifically includes: For each of the directed edges, the corresponding processing method is input into the code generation agent; If modifications are required, the code generation agent determines update information based on each Android page, control tree, and Android state transition relationship, and modifies each Android page according to the update information to obtain the corresponding HarmonyOS page; If generation is required, the code generation agent analyzes all the Android pages in the directed edges to obtain multiple target interface screenshots and control trees. Based on each target interface screenshot and control tree, a corresponding HarmonyOS page is constructed. Based on the Android state transition relationship, the interaction logic and navigation logic between the two HarmonyOS pages are generated.

[0011] Optionally, the mobile application migration method based on state transition diagrams and dynamic verification, wherein compiling all the HarmonyOS pages to obtain an initial HarmonyOS application package, installing the initial HarmonyOS application package onto the HarmonyOS device for dynamic verification, and modifying multiple HarmonyOS pages until verification succeeds to obtain an intermediate HarmonyOS application package, specifically includes: Perform static compilation on all the aforementioned HarmonyOS pages; If compilation is successful, all the HarmonyOS pages will be packaged into an initial HarmonyOS application package. If compilation fails, the problematic HarmonyOS pages will be modified until the initial HarmonyOS application package is obtained. Run the initial HarmonyOS application package to construct the HarmonyOS state transition graph in the same way as the state transition graph of the Android application; Based on the state transition diagram of the Android application, the HarmonyOS state transition diagram is monitored to obtain the HarmonyOS page that does not conform to the Android page, and the interaction logic and navigation logic that do not conform to the Android state transition relationship. Based on the corresponding Android page and the corresponding Android state transition relationship, all HarmonyOS pages, all interaction logics and all navigation logics that do not conform are repaired to finally obtain the intermediate HarmonyOS application package.

[0012] Optionally, the mobile application migration method based on state transition diagrams and dynamic verification, wherein monitoring all HarmonyOS pages while running the intermediate HarmonyOS application package, and optimizing multiple HarmonyOS pages according to the corresponding Android pages to obtain the target HarmonyOS application package, specifically includes: When running the intermediate HarmonyOS application package, all HarmonyOS pages are monitored, and all HarmonyOS pages and their corresponding Android pages are input into the interface parsing model. The interface parsing model analyzes all components of the corresponding HarmonyOS page and Android page, and constructs corresponding code patches based on the differences between each pair of components; Each HarmonyOS page is finely adjusted based on each code patch to obtain a portable target HarmonyOS application package.

[0013] Furthermore, to achieve the above objectives, the present invention also provides a mobile application migration system based on state transition diagrams and dynamic verification, wherein the mobile application migration system based on state transition diagrams and dynamic verification includes: The offline analysis module is used to obtain various runtime information of the Android application while it is running, and to construct a state transition diagram of the Android application based on all the runtime information. The code generation module is used to perform edge traversal on the state transition graph to obtain an action sequence, and to model all Android pages in the state transition graph based on the action sequence to obtain the corresponding HarmonyOS page; The static compilation and dynamic verification module is used to compile all the HarmonyOS pages to obtain an initial HarmonyOS application package, install the initial HarmonyOS application package on the HarmonyOS device for dynamic verification, and modify multiple HarmonyOS pages until verification is successful to obtain an intermediate HarmonyOS application package. When running the intermediate HarmonyOS application package, it monitors all the HarmonyOS pages and optimizes multiple HarmonyOS pages according to the corresponding Android pages to obtain the target HarmonyOS application package.

[0014] Furthermore, to achieve the above objectives, the present invention also provides a terminal, wherein the terminal includes: a memory, a processor, and a mobile application migration program based on state transition diagrams and dynamic verification stored in the memory and executable on the processor, wherein when the mobile application migration program based on state transition diagrams and dynamic verification is executed by the processor, it implements the steps of the mobile application migration method based on state transition diagrams and dynamic verification as described above.

[0015] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a mobile application migration program based on a state transition diagram and dynamic verification, and the mobile application migration program based on a state transition diagram and dynamic verification, when executed by a processor, implements the steps of the mobile application migration method based on a state transition diagram and dynamic verification as described above.

[0016] In this invention, when running an Android application, various runtime information of the Android application is acquired, and a state transition graph of the Android application is constructed based on all the runtime information. The state transition graph is traversed edge-wise to obtain an action sequence. Based on the action sequence, all Android pages in the state transition graph are modeled to obtain corresponding HarmonyOS pages. All HarmonyOS pages are compiled to obtain an initial HarmonyOS application package. The initial HarmonyOS application package is installed on a HarmonyOS device for dynamic verification. If verification fails, multiple HarmonyOS pages are modified until verification succeeds, resulting in an intermediate HarmonyOS application package. While running the intermediate HarmonyOS application package, all HarmonyOS pages are monitored, and multiple HarmonyOS pages are optimized based on the corresponding Android pages to obtain the target HarmonyOS application package. This invention can generate a complete, compileable, installable, and runnable HarmonyOS application even without the original application source code, while better preserving the original application's interface appearance and interaction logic. It reduces page relationship inference errors and runtime interaction anomalies, effectively improving the reliability and practical usability of cross-system application migration results. Attached Figure Description

[0017] Figure 1 This is a flowchart of a preferred embodiment of the mobile application migration method based on state transition diagrams and dynamic verification of the present invention; Figure 2 This is an overall flowchart of a preferred embodiment of the mobile application migration method based on state transition diagrams and dynamic verification of the present invention; Figure 3 This is a structural diagram of a preferred embodiment of the mobile application migration system based on state transition diagrams and dynamic verification of the present invention; Figure 4 This is a structural diagram of a preferred embodiment of the terminal of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0019] Cross-platform migration of mobile applications is a long-standing engineering problem in the field of software engineering. Different mobile operating systems typically employ different development languages, interface frameworks, routing mechanisms, build toolchains, and application package formats. When a new mobile ecosystem emerges or enterprises need to quickly extend the same business to multiple platforms, developers often need to repeatedly implement interface layouts, interaction logic, page navigation, resource references, and system API calls, which is costly, time-consuming, and prone to introducing inconsistent user experiences.

[0020] The mobile application migration method based on state transition diagrams and dynamic verification described in the preferred embodiment of the present invention, such as... Figure 1 As shown, the mobile application migration method based on state transition diagrams and dynamic verification includes the following steps: Step S10: When running an Android application, obtain various running information of the Android application, and construct a state transition diagram of the Android application based on all the running information.

[0021] In the embodiments disclosed in this invention, the overall system comprises two main parts: offline analysis and online generation. The offline analysis part is used to extract real runtime information from the original Android application and organize HarmonyOS development-related resources. The online generation part is used to gradually generate, repair, and verify the HarmonyOS ArkTS project (Ark TypeScript, the primary application development language exclusive to the HarmonyOS operating system) under the guidance of the state transition diagram.

[0022] Specifically, the step of obtaining various runtime information of the Android application while running the application, and constructing a state transition diagram of the Android application based on all the runtime information, specifically includes: Install the Android application package and run the corresponding Android application. During runtime, collect all Android pages and all execution actions of the Android application. Each Android page is defined as a corresponding node, and the execution action between any two Android pages is defined as a corresponding edge; For each edge, each edge and the two nodes connecting the edge are defined as a directed edge. The state transition graph of the Android application is constructed based on all the directed edges and all the nodes.

[0023] The initial input is the Android application installation package to be migrated; the Android application source code is not required. The system runs the Android application using an automated graphical interface exploration tool, and collects runtime information such as screenshots, control tree, currently executable actions, and the target interface state (i.e., the Android page) after the actions are executed. Based on this information, a user interface state transition graph is constructed.

[0024] In the constructed state transition graph, an Android application's interface state is used as a node, storing screenshots and the control hierarchy of that interface. For other nodes related to the current node, their sequential relationship is represented by directed edges. That is, a user action on the current interface (such as clicking, long-pressing, swiping, or text input) allows a user to transition from the current node's state to another node; this state transition process is represented by the directed edge between the two nodes. In this way, the actual execution process of the original Android application is abstracted into a graph structure. The subsequent HarmonyOS application generation process can then unfold step-by-step according to this graph structure. Thus, the state transition graph is not statically inferred from multiple screenshots but comes from the actual execution process of the original application. Therefore, it can more accurately record the real interaction relationships between and within pages, reducing problems such as incorrect page relationships, invalid jumps, and missing interaction logic.

[0025] Specifically, by automatically exploring and constructing an Android application state transition graph, and using this graph as the basis for generating HarmonyOS applications, the migration process can be based on the actual running behavior of the original application, rather than relying solely on source code or static screenshots.

[0026] It is important to note that the offline analysis portion disclosed in this invention also includes resources related to the HarmonyOS development process. These resources serve as tools for subsequent intelligent agents to utilize, enabling enhanced retrieval and generation. For example, they include ArkTS language resources, ArkUI framework (Ark User Interface) development documentation resources, and HarmonyOS system symbol resources. The ArkTS language can query HarmonyOS development-related documentation, while the ArkUI framework development documentation resources can query system icon names such as SymbolGlyph (a standard component name in HarmonyOS ArkTS development). The system can construct retrieve_arkts_docs and search_symbols retrieval tools respectively using a vector database, providing HarmonyOS platform-related knowledge to the large model during subsequent code generation and repair processes.

[0027] The offline analysis component disclosed in this invention explores and constructs a state transition graph through real-world operation, providing a reliable application-level knowledge graph structure for the migration process, and enhances retrieval capabilities for code generation and repair through the organization of HarmonyOS development resources.

[0028] Step S20: Perform edge traversal on the state transition graph to obtain an action sequence, and model all Android pages in the state transition graph according to the action sequence to obtain the corresponding HarmonyOS page.

[0029] In the embodiments disclosed in this invention, such as Figure 2As shown, the online generation section further includes a code generation stage, a static compilation stage, and a dynamic verification stage. The online generation section uses the state transition graph obtained from offline analysis as its core input. It obtains the edge traversal order (i.e., the action sequence) through a specific graph traversal method (such as breadth-first search), and generates the HarmonyOS ArkTS project step by step according to this order. For each directed edge in the state transition graph (represented by a triple: <current interface node, action, target interface node>), the system reads its current interface state, target interface state, and the user action that triggered the transition, and then sequentially executes code generation, static compilation, and dynamic verification around that state transition edge.

[0030] Specifically, starting from the home screen of the Android application, all directed edges in the state transition graph are traversed to generate an action sequence for running the Android application. Based on the action sequence, determine whether there is a HarmonyOS page corresponding to the Android page in the HarmonyOS resource library, and determine the processing method for obtaining the HarmonyOS page based on the determination result. Each of the aforementioned processing methods is input into the code generation agent, which outputs the HarmonyOS page corresponding to each of the aforementioned Android pages.

[0031] The code generation phase first determines the HarmonyOS project organization method corresponding to the current state, that is, whether the current target state should be written to an existing page file or a new page file should be generated. In the embodiments disclosed in this invention, when performing page modeling, the modeling is performed by combining the Activity (the basic component that carries the user interaction interface) information in the Android application and the state transition diagram relationship, rather than simply generating each screenshot as an independent page.

[0032] Furthermore, based on the action sequence, the Android state transition relationship between each directed edge Android page and the two Android pages is determined; For each of the directed edges, determine in the HarmonyOS resource library whether there are multiple initial HarmonyOS pages and HarmonyOS state transition relationships corresponding to all the Android pages and the Android state transition relationships; If they exist, then all corresponding HarmonyOS pages will be obtained by modifying all the initial HarmonyOS pages. If it does not exist, then all corresponding HarmonyOS pages will be obtained by constructing new pages.

[0033] When generating the HarmonyOS project, the Android application's Activities are modeled in correspondence with HarmonyOS's NavDestination (a type of subpage container component). Each Activity corresponds to a HarmonyOS ArkTS file, with NavDestination as the root node, representing a page within the HarmonyOS application. For state changes within the same Activity, such as bottom bar switching, pop-up display, and partial content refresh, this invention does not create a new independent HarmonyOS page file. Instead, incremental modifications are made to the corresponding NavDestination page file to treat these as state changes within the same page. If state changes exist between different Activities, a new NavDestination page file is generated. This page information is written to the route_map.json file (a configuration file for page decoupling and dynamic route navigation) to complete page route registration, and navigation between pages is performed using Navigation-related APIs. In this way, the system can clearly determine which content is written to existing files and which is written to new files, reducing the problem of modeling in-page interaction errors as cross-page navigation at the project structure level.

[0034] Furthermore, for each of the directed edges, the corresponding processing method is input into the code generation agent; If modifications are required, the code generation agent determines update information based on each Android page, control tree, and Android state transition relationship, and modifies each Android page according to the update information to obtain the corresponding HarmonyOS page; If generation is required, the code generation agent analyzes all the Android pages in the directed edges to obtain multiple target interface screenshots and control trees. Based on each target interface screenshot and control tree, a corresponding HarmonyOS page is constructed. Based on the Android state transition relationship, the interaction logic and navigation logic between the two HarmonyOS pages are generated.

[0035] After determining the page modeling method, the code generation agent generates or modifies code based on the current state transition. If the target interface state has not yet been generated, the code generation agent generates new page state code based on the screenshot, control tree, and action information of the target interface. Simultaneously, it generates corresponding interaction and navigation logic based on the action information from the current state to the target state. If the target interface state has already been generated, the code generation agent only needs to supplement or modify the event handling, state variables, page transition, or partial interface update code related to the current transition.

[0036] Furthermore, the system requests a code generation agent to generate or modify HarmonyOS ArkTS code. This code generation agent is based on a multimodal large model, and its inputs include screenshots of the source state corresponding to the current state transition edge, screenshots of the target state, the target state control tree, the source action, and the existing HarmonyOS project code. Page modeling requirements are used to inform the agent whether the current content should be written to an existing NavDestination page file or a new NavDestination page file should be generated. NavDestination needs to be used in conjunction with the Navigation component (a routing container component) and serves as the root node of the navigation target page. Navigation is suitable for page routing and page stack management.

[0037] Before inputting the code generation agent, the system simplifies and standardizes the Android control tree. Specifically, the system retains information directly related to interface generation, such as control type, text content, semantic description, and coordinate boundaries, while removing redundant attributes. Simultaneously, the system converts the original boundary information into length, width, and other formats, making the position and size of interface components easier for the large model to understand. In the prompts, the system instructs the code generation agent to use pixels as the unit when generating values ​​related to distance, position, width, height, spacing, and margins, and to maintain consistency with the coordinates and dimensions in the original Android screenshot as much as possible. This reduces layout errors caused by unit conversions, allowing the position and size information in the Android control tree to be mapped more directly to the HarmonyOS ArkUI code. Furthermore, the system provides the code generation agent with a HarmonyOS development resource retrieval tool to enhance the generation effect of the large model, using the vector database built in the offline phase as a tool for the agent. During the generation process, if the agent is unsure about the usage of a certain ArkUI component, attribute, or system icon name, it can call the corresponding tool to search and then generate code based on the search results, improving code accuracy.

[0038] Step S30: After compiling all the HarmonyOS pages, an initial HarmonyOS application package is obtained. The initial HarmonyOS application package is installed on the HarmonyOS device for dynamic verification. If the verification fails, multiple HarmonyOS pages are modified until the verification is successful to obtain an intermediate HarmonyOS application package. When running the intermediate HarmonyOS application package, all HarmonyOS pages are monitored, and multiple HarmonyOS pages are optimized according to the corresponding Android pages to obtain the target HarmonyOS application package.

[0039] Specifically, all the HarmonyOS pages are statically compiled; If compilation is successful, all the HarmonyOS pages will be packaged into an initial HarmonyOS application package. If compilation fails, the problematic HarmonyOS pages will be modified until the initial HarmonyOS application package is obtained. Run the initial HarmonyOS application package to construct the HarmonyOS state transition graph in the same way as the state transition graph of the Android application; Based on the state transition diagram of the Android application, the HarmonyOS state transition diagram is monitored to obtain the HarmonyOS page that does not conform to the Android page, and the interaction logic and navigation logic that do not conform to the Android state transition relationship. Based on the corresponding Android page and the corresponding Android state transition relationship, all HarmonyOS pages, all interaction logics and all navigation logics that do not conform are repaired to finally obtain the intermediate HarmonyOS application package.

[0040] The code generation agent generates new code and then performs static compilation on the entire HarmonyOS project. If compilation succeeds, the compiled project is packaged into a Harmony Ability Package (HAP) and enters the dynamic verification phase. If compilation fails, the code repair agent iteratively repairs the code based on the error information returned by the compiler, relevant source code fragments, and HarmonyOS development resource retrieval results until compilation succeeds or the preset maximum number of repairs is reached, providing a foundation for subsequent real-device operation verification.

[0041] The fact that the code can be compiled does not mean that the migrated application can run correctly, nor does it mean that the state transition relationships in the original Android application have been correctly implemented. Therefore, this invention introduces a dynamic verification stage after static compilation, installing the generated HAP on a real HarmonyOS device and performing navigation, navigation repair, and improvements to the newly generated UI around the state transition edge to be verified.

[0042] Specifically, when running the intermediate HarmonyOS application package, all HarmonyOS pages are monitored, and all HarmonyOS pages and their corresponding Android pages are input into the interface parsing model. The interface parsing model analyzes all components of the corresponding HarmonyOS page and Android page, and constructs corresponding code patches based on the differences between each pair of components; Each HarmonyOS page is finely adjusted based on each code patch to obtain a portable target HarmonyOS application package.

[0043] For the state transition edge that needs to be verified, the system first calculates the path from the home screen state to the current source screen state based on the generated HarmonyOS state transition graph. The navigation agent then performs the corresponding operation on the real HarmonyOS device to bring the application to the source screen state that needs verification. Subsequently, the navigation agent selects the most likely corresponding HarmonyOS operation based on the original Android source state screenshot, the original Android trigger action, the current HarmonyOS screenshot, and the executable actions in the current HarmonyOS interface, and executes the operation on the real device. After execution, the system obtains the new HarmonyOS screenshot and the current UI state, and determines whether they match the target state in the original Android state transition graph.

[0044] If the navigation verification detects that the current HarmonyOS application cannot complete the expected state transition, the navigation repair agent will be triggered. Common reasons for state transition failure include: missing page jump interaction logic, abnormal configuration of clickable areas of components, control layer obstruction causing trigger failure, and code logic errors causing runtime crashes. After the repair is completed, the system recompiles and installs the application and performs navigation verification again, iterating until the corresponding state transition verification passes or the preset maximum number of repair attempts is reached.

[0045] The process involves installing the generated HarmonyOS application onto a real device and running it, then automatically navigating to verify whether the state transition can be executed correctly. Based on the results, navigation is repaired and the interface is improved, thereby enhancing the app's operability, interaction correctness, visual consistency, and usability after migration.

[0046] Furthermore, if navigation verification indicates that the current state transition has been successfully completed, the system proceeds to the interface improvement process to enhance the visual consistency between the target HarmonyOS interface and the original Android interface. Specifically, the system inputs the original Android target screenshot and the current HarmonyOS screenshot into an interface analysis tool to extract the visible UI components and their position information from both screenshots. Then, the interface improvement agent analyzes the differences between the two screenshots—including the original screenshot, the actual screenshot, the UI component information on both sides, and the relevant source code of the current page—in terms of component position, size, spacing, alignment, text layout, and image areas. It then generates corresponding code patches to make fine-grained adjustments to the HarmonyOS page. While ensuring the correctness of the state transition, this further optimizes the page's visual effects, making the migrated application more closely resemble the original Android application in terms of interface structure and visual appearance.

[0047] The online generation method disclosed in this invention generates the HarmonyOS ArkTS project step by step based on the state transition diagram, and improves the compilability, runnability, interaction correctness, and visual consistency of the project through code generation, static compilation, and dynamic verification. Compared with existing methods that rely on source code conversion or generate code based solely on screenshots, this invention can generate HarmonyOS applications that can both reproduce the appearance of static Android pages and completely replicate the interaction logic between different interface states, making it more practical.

[0048] This invention can generate a complete, compileable, installable, and runnable HarmonyOS application even in the absence of the original application's source code, while better preserving the original application's interface appearance and interaction logic. It reduces page relationship inference errors and runtime interaction anomalies, effectively improving the reliability and practical usability of cross-system application migration results.

[0049] Furthermore, such as Figure 3 As shown, based on the above-described mobile application migration method based on state transition diagrams and dynamic verification, this invention also provides a mobile application migration system based on state transition diagrams and dynamic verification, wherein the mobile application migration system based on state transition diagrams and dynamic verification includes: The offline analysis module 51 is used to obtain various running information of the Android application when the Android application is running, and to construct a state transition diagram of the Android application based on all the running information. Code generation module 52 is used to perform edge traversal on the state transition graph to obtain an action sequence, and to model all Android pages in the state transition graph based on the action sequence to obtain the corresponding HarmonyOS page; The static compilation and dynamic verification module 53 is used to compile all the HarmonyOS pages to obtain an initial HarmonyOS application package, install the initial HarmonyOS application package on the HarmonyOS device for dynamic verification, modify multiple HarmonyOS pages if verification fails, until verification succeeds to obtain an intermediate HarmonyOS application package, monitor all the HarmonyOS pages while running the intermediate HarmonyOS application package, optimize multiple HarmonyOS pages according to the corresponding Android pages, and obtain the target HarmonyOS application package.

[0050] Furthermore, such as Figure 4 As shown, based on the above-mentioned mobile application migration method and system based on state transition diagram and dynamic verification, the present invention also provides a terminal, which includes a processor 10, a memory 20 and a display 30. Figure 4 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0051] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard disk or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc. Further, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as the program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores a mobile application migration program 40 based on a state transition diagram and dynamic verification. This mobile application migration program 40 based on a state transition diagram and dynamic verification can be executed by the processor 10, thereby implementing the mobile application migration method based on a state transition diagram and dynamic verification in this application.

[0052] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing the mobile application migration method based on state transition diagram and dynamic verification.

[0053] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. The display 30 is used to display information on the terminal and to display a visual user interface. The components of the terminal communicate with each other via a system bus.

[0054] In one embodiment, when the processor 10 executes the mobile application migration program 40 based on state transition diagrams and dynamic verification in the memory 20, it implements the steps of the mobile application migration method based on state transition diagrams and dynamic verification as described above.

[0055] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a mobile application migration program based on a state transition diagram and dynamic verification, and the mobile application migration program based on a state transition diagram and dynamic verification, when executed by a processor, implements the steps of the mobile application migration method based on a state transition diagram and dynamic verification as described above.

[0056] In summary, this invention provides a mobile application migration method and related equipment based on state transition graphs and dynamic verification. The method includes: acquiring various runtime information of an Android application while it is running; constructing a state transition graph of the Android application based on all the runtime information; performing edge traversal on the state transition graph to obtain an action sequence; modeling all Android pages in the state transition graph based on the action sequence to obtain corresponding HarmonyOS pages; compiling all the HarmonyOS pages to obtain an initial HarmonyOS application package; installing the initial HarmonyOS application package on a HarmonyOS device for dynamic verification; if verification fails, modifying multiple HarmonyOS pages until verification succeeds to obtain an intermediate HarmonyOS application package; monitoring all the HarmonyOS pages while running the intermediate HarmonyOS application package; optimizing multiple HarmonyOS pages based on the corresponding Android pages to obtain a target HarmonyOS application package. This invention can generate a complete, compilable, installable, and runnable HarmonyOS application even without the original application source code, while better preserving the original application's interface appearance and interaction logic, reducing page relationship inference errors and runtime interaction anomalies, and effectively improving the reliability and practical usability of cross-system application migration results.

[0057] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0058] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.). The program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The computer-readable storage medium can be a memory, magnetic disk, optical disk, etc.

[0059] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A mobile application migration method based on state transition diagrams and dynamic verification, characterized in that, The mobile application migration method based on state transition diagrams and dynamic verification includes: When running an Android application, various runtime information of the Android application is obtained, and a state transition diagram of the Android application is constructed based on all the runtime information. The action sequence is obtained by traversing the edges of the state transition graph. Based on the action sequence, all Android pages in the state transition graph are modeled to obtain the corresponding HarmonyOS pages. After compiling all the HarmonyOS pages, an initial HarmonyOS application package is obtained. The initial HarmonyOS application package is installed on the HarmonyOS device for dynamic verification. If the verification fails, multiple HarmonyOS pages are modified until the verification is successful, resulting in an intermediate HarmonyOS application package. When running the intermediate HarmonyOS application package, all HarmonyOS pages are monitored, and multiple HarmonyOS pages are optimized according to the corresponding Android pages to obtain the target HarmonyOS application package.

2. The mobile application migration method based on state transition diagram and dynamic verification according to claim 1, characterized in that, The operational information includes: Android page and executed actions; The step of obtaining various runtime information of the Android application while it is running, and constructing a state transition diagram of the Android application based on all the runtime information, specifically includes: Install the Android application package and run the corresponding Android application. During runtime, collect all Android pages and all execution actions of the Android application. Each Android page is defined as a corresponding node, and the execution action between any two Android pages is defined as a corresponding edge; For each edge, each edge and the two nodes connecting the edge are defined as a directed edge. The state transition graph of the Android application is constructed based on all the directed edges and all the nodes.

3. The mobile application migration method based on state transition diagram and dynamic verification according to claim 1, characterized in that, The process of traversing the state transition graph to obtain an action sequence, and then modeling all Android pages in the state transition graph based on the action sequence to obtain the corresponding HarmonyOS page, specifically includes: Starting from the home screen of the Android application, all directed edges in the state transition graph are traversed to generate an action sequence for running the Android application. Based on the action sequence, determine whether there is a HarmonyOS page corresponding to the Android page in the HarmonyOS resource library, and determine the processing method for obtaining the HarmonyOS page based on the determination result. Each of the aforementioned processing methods is input into the code generation agent, which outputs the HarmonyOS page corresponding to each of the aforementioned Android pages.

4. The mobile application migration method based on state transition diagram and dynamic verification according to claim 3, characterized in that, The step of determining whether a HarmonyOS page corresponding to the Android page exists in the HarmonyOS resource library based on the action sequence, and determining the processing method for each Android page based on the determination result, specifically includes: Based on the action sequence, determine the Android page for each directed edge and the Android state transition relationship between the two Android pages; For each of the directed edges, determine in the HarmonyOS resource library whether there are multiple initial HarmonyOS pages and HarmonyOS state transition relationships corresponding to all the Android pages and the Android state transition relationships; If they exist, then all corresponding HarmonyOS pages will be obtained by modifying all the initial HarmonyOS pages. If it does not exist, then all corresponding HarmonyOS pages will be obtained by constructing new pages.

5. The mobile application migration method based on state transition diagram and dynamic verification according to claim 4, characterized in that, The step of inputting each of the aforementioned processing methods into the code generation agent and outputting the HarmonyOS page corresponding to each of the aforementioned Android pages specifically includes: For each of the directed edges, the corresponding processing method is input into the code generation agent; If modifications are required, the code generation agent determines update information based on each Android page, control tree, and Android state transition relationship, and modifies each Android page according to the update information to obtain the corresponding HarmonyOS page; If generation is required, the code generation agent analyzes all the Android pages in the directed edges to obtain multiple target interface screenshots and control trees. Based on each target interface screenshot and control tree, a corresponding HarmonyOS page is constructed. Based on the Android state transition relationship, the interaction logic and navigation logic between the two HarmonyOS pages are generated.

6. The mobile application migration method based on state transition diagram and dynamic verification according to claim 5, characterized in that, The process involves compiling all the HarmonyOS pages to obtain an initial HarmonyOS application package. This initial HarmonyOS application package is then installed on a HarmonyOS device for dynamic verification. If verification fails, multiple HarmonyOS pages are modified until verification succeeds, resulting in an intermediate HarmonyOS application package. This package specifically includes: Perform static compilation on all the aforementioned HarmonyOS pages; If compilation is successful, all the HarmonyOS pages will be packaged into an initial HarmonyOS application package. If compilation fails, the problematic HarmonyOS pages will be modified until the initial HarmonyOS application package is obtained. Run the initial HarmonyOS application package to construct the HarmonyOS state transition graph in the same way as the state transition graph of the Android application; Based on the state transition diagram of the Android application, the HarmonyOS state transition diagram is monitored to obtain the HarmonyOS page that does not conform to the Android page, and the interaction logic and navigation logic that do not conform to the Android state transition relationship. Based on the corresponding Android page and the corresponding Android state transition relationship, all HarmonyOS pages, all interaction logics and all navigation logics that do not conform are repaired to finally obtain the intermediate HarmonyOS application package.

7. The mobile application migration method based on state transition diagram and dynamic verification according to claim 1, characterized in that, The process of monitoring all HarmonyOS pages while running the intermediate HarmonyOS application package, and optimizing multiple HarmonyOS pages based on their corresponding Android pages to obtain the target HarmonyOS application package, specifically includes: When running the intermediate HarmonyOS application package, all HarmonyOS pages are monitored, and all HarmonyOS pages and their corresponding Android pages are input into the interface parsing model. The interface parsing model analyzes all components of the corresponding HarmonyOS page and Android page, and constructs corresponding code patches based on the differences between each pair of components; Each HarmonyOS page is finely adjusted based on each code patch to obtain a portable target HarmonyOS application package.

8. A mobile application migration system based on state transition diagrams and dynamic verification, characterized in that, The mobile application migration system based on state transition diagrams and dynamic verification is used to implement the mobile application migration method based on state transition diagrams and dynamic verification as described in any one of claims 1-7, wherein the mobile application migration system based on state transition diagrams and dynamic verification includes: The offline analysis module is used to obtain various runtime information of the Android application while it is running, and to construct a state transition diagram of the Android application based on all the runtime information. The code generation module is used to perform edge traversal on the state transition graph to obtain an action sequence, and to model all Android pages in the state transition graph based on the action sequence to obtain the corresponding HarmonyOS page; The static compilation and dynamic verification module is used to compile all the HarmonyOS pages to obtain an initial HarmonyOS application package, install the initial HarmonyOS application package on the HarmonyOS device for dynamic verification, modify multiple HarmonyOS pages if verification fails, until verification succeeds to obtain an intermediate HarmonyOS application package, monitor all the HarmonyOS pages while running the intermediate HarmonyOS application package, optimize multiple HarmonyOS pages according to the corresponding Android pages, and obtain the target HarmonyOS application package.

9. A terminal, characterized in that, The terminal includes: a memory, a processor, and a mobile application migration program based on state transition diagrams and dynamic verification stored in the memory and executable on the processor. When the mobile application migration program based on state transition diagrams and dynamic verification is executed by the processor, it implements the steps of the mobile application migration method based on state transition diagrams and dynamic verification as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a mobile application migration procedure based on a state transition diagram and dynamic verification, which, when executed by a processor, implements the steps of the mobile application migration method based on a state transition diagram and dynamic verification as described in any one of claims 1-7.

Images