Method for running application across systems and electronic device

Abstract

The application is suitable for the terminal technical field, and provides a method for running an application program across systems and an electronic device.The method comprises the following steps: displaying a first interface of a target application program in a first software system, the target application program running in a second software system; feeding back an input event to the target application program through the second software system, obtaining a second interface refreshed by the target application program, and the input event being triggered for the first interface in the first software system; and replacing the first interface in the first software system with the second interface, so that the target application program running in the second software system can be displayed in the first software system without difference, the difference between different versions of the target application program matched with different software systems can be avoided, the diversity of the terminal device running different application programs can be improved, and the adaptability of the terminal device in different scenes can be improved.

Description

Technical Field

[0001] This application relates to the field of terminal device technology, and in particular to a method and electronic device for running applications across systems. Background Technology

[0002] Different terminal devices can run different software systems, and different software systems can install different applications to suit different scenarios. For example, mobile phones running the Android system can install instant messaging applications, while computers running Windows or Linux systems can install office applications.

[0003] With the continuous development of terminal devices, the same application can be developed into versions compatible with different software systems, allowing terminal devices to be used in more scenarios after installing the application that matches the software system. However, there are significant differences between the various versions of the same application that are compatible with different software systems. Summary of the Invention

[0004] This application provides a method and electronic device for running applications across systems, which solves the problem in the prior art that there are large differences between different versions of the same application that are compatible with different software systems.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] In a first aspect, a method for running applications across systems is provided, applied to an electronic device, wherein the electronic device carries a first software system and a second software system, and the second software system runs based on the first software system, the method comprising:

[0007] The first interface of the target application is displayed in the first software system, and the target application runs in the second software system;

[0008] The second software system feeds back an input event to the target application, thereby obtaining a refreshed second interface of the target application. The input event is triggered in the first software system for the first interface.

[0009] Replace the first interface in the first software system with the second interface.

[0010] The first software system displays the target application's initial interface, which is then replaced with a refreshed second interface based on input events. This allows for seamless display of the target application running in the second software system within the first system, without requiring the target application to be run on the first system itself. This avoids discrepancies between different versions of the target application compatible with different software systems. Furthermore, based on input events collected by the first software system, the target application's interface can also be refreshed within that system, enabling interaction between the user and the target application running in the second system. This enhances the versatility of the terminal device in running different applications and improves its adaptability to various scenarios.

[0011] In a first possible implementation of the first aspect, the first software system is an Android system and the second software system is a Linux system.

[0012] Based on any of the possible implementations of the first aspect described above, in a second possible implementation of the first aspect, before displaying the first interface of the target application in the first software system, the method further includes:

[0013] Send startup information from the first software system to the second software system;

[0014] The target application is launched in the second software system according to the startup information, and the first interface is obtained.

[0015] Based on the second possible implementation of the first aspect, in the third possible implementation of the first aspect, the step of sending startup information from the first software system to the second software system includes:

[0016] Based on the operation triggered in the first software system, the proxy Android application package APK is launched in the first software system;

[0017] The startup information is composed of the startup signaling obtained through the main activity of the proxy APK, the storage path of the target application, and the application identifier of the target application;

[0018] The startup information is sent from the first software system to the second software system through the management and communication layers of the proxy APK.

[0019] Based on the second possible implementation of the first aspect, in the fourth possible implementation of the first aspect, the startup information includes: startup signaling, the storage path of the target application, and the application identifier of the target application;

[0020] The step of launching the target application in the second software system according to the startup information to obtain the first interface includes:

[0021] The second software system locates the target application based on the startup signaling, combined with the storage path and application identifier of the target application;

[0022] Launch the target application to obtain the first interface generated by the target application.

[0023] Based on the fourth possible implementation of the first aspect, in the fifth possible implementation of the first aspect, launching the target application and obtaining the first interface generated by the target application includes:

[0024] The target application requests a window from the window service of the second software system and obtains the window allocated to the target application by the window service;

[0025] The target application draws the first interface based on the window allocated by the window service and in conjunction with the resources of the target application.

[0026] Based on any of the possible implementations of the first aspect described above, in the sixth possible implementation of the first aspect, the step of displaying the first interface of the target application in the first software system includes:

[0027] The first software system receives the first interface, window information, and creation signaling sent by the second software system through window services via a proxy APK. The window information is used to represent the information of the window allocated by the window service of the second software system to the target application.

[0028] The proxy APK, based on the creation signaling and in conjunction with the Activity Management Service (AMS) of the first software system, creates an application activity corresponding to the target application in the first software system.

[0029] The proxy APK displays the first interface in the first software system through the application activity, combined with the first interface and the window information.

[0030] By using a proxy APK, one or more app activities can be created in the first software system. By combining the created one or more app activities, the interface corresponding to one or more applications running in the second software system can be displayed simultaneously in the first software system, which can further improve the adaptability and versatility of terminal device applications in different scenarios.

[0031] Based on the sixth possible implementation of the first aspect, in the seventh possible implementation of the first aspect, the window information includes the window identifier corresponding to the target application;

[0032] Before the second software system feeds back the input event to the target application and obtains the refreshed second interface of the target application, the method further includes:

[0033] The proxy APK establishes a correspondence between the window identifier corresponding to the target application and the application activity corresponding to the target application through the management layer.

[0034] By establishing a correspondence between the window identifiers of app activities and target applications, the time required to refresh the target application's interface in the first software system can be reduced, and the synchronization of window management and lifecycle between app activities and target applications can be achieved.

[0035] Based on any of the above possible implementations of the first aspect, in the eighth possible implementation of the first aspect, before the second software system feeds back the input event to the target application and obtains the refreshed second interface of the target application, the method further includes:

[0036] The input events triggered are collected in the first software system;

[0037] The input events are fed back from the first software system to the second software system through the proxy APK.

[0038] Based on the eighth possible implementation of the first aspect, in the ninth possible implementation of the first aspect, the step of collecting the triggered input event in the first software system includes:

[0039] The input events are collected through the Input Management Service (IMS) of the first software system;

[0040] The input event is forwarded to the application activity corresponding to the target application through the Window Management Service (WMS) of the first software system.

[0041] Based on the eighth possible implementation of the first aspect, in the tenth possible implementation of the first aspect, the step of feeding back the input event from the first software system to the second software system via the proxy APK includes:

[0042] The proxy APK feeds back the input events received by the application activity corresponding to the target application to the second software system through the management layer and the communication layer.

[0043] Based on any one of the eighth to tenth possible implementations of the first aspect, in the eleventh possible implementation of the first aspect, the step of collecting the triggered input event in the first software system includes:

[0044] Obtain the input type of the input event and the stacking relationship between windows in the first software system;

[0045] If the input type of the input event is key input and the window corresponding to the target application is in the foreground, then the input event is collected;

[0046] If the input type of the input event is mouse input or touch screen input, then the window corresponding to the input event is determined based on the position of the input event and the stacking relationship between windows in the first software system.

[0047] If the window corresponding to the input event is the window corresponding to the target application, then the input event is collected.

[0048] The first software system collects input events based on the window currently in the foreground. If the window in the foreground is the window corresponding to the target application, the first software system can send the collected input events back to the second software system. The system can then obtain and display the interface redrawn by the target application based on the input events. This can solve the problems of collecting input events triggered by the target application in the first software system and improve the accuracy of collecting input events for the target application.

[0049] Based on any of the possible implementations of the first aspect described above, in the twelfth possible implementation of the first aspect, the step of feeding back an input event to the target application through the second software system to obtain the refreshed second interface of the target application includes:

[0050] The input event is received through the window service of the second software system, and the input event is mapped to the target application.

[0051] The target application redraws its interface based on the mapped input events to obtain the second interface.

[0052] Based on any of the above possible implementations of the first aspect, in the thirteenth possible implementation of the first aspect, replacing the first interface in the first software system with the second interface includes:

[0053] The window service of the second software system provides feedback on the window information of the second interface and the target application to the proxy APK.

[0054] The proxy APK replaces the first interface corresponding to the target application in the first software system with the second interface based on the second interface and the window information of the target application.

[0055] Based on the thirteenth possible implementation of the first aspect, in the fourteenth possible implementation of the first aspect, the proxy APK replaces the first interface corresponding to the target application in the first software system with the second interface according to the second interface and the window information of the target application, including:

[0056] The proxy APK receives window information from the second interface and the target application through the communication layer;

[0057] The proxy APK, through the management layer, searches for the application activity corresponding to the window information based on the correspondence between the window identifier corresponding to the target application and the application activity corresponding to the target application.

[0058] The proxy APK sends the second interface to the application activity corresponding to the window information through the management layer, replacing the first interface with the second interface.

[0059] Based on any of the above possible implementations of the first aspect, in the fifteenth possible implementation of the first aspect, the input events include: window size adjustment operation, window position adjustment operation, and window function interaction operation.

[0060] Secondly, embodiments of this application provide an apparatus for running applications across systems, the apparatus being included in an electronic device, the apparatus having the functionality to implement the method for running applications across systems as described in any of the first aspects above.

[0061] Thirdly, an electronic device is provided, comprising: a processor for running a computer program stored in a memory, such that the electronic device implements a method for running an application across systems as described in any one of the first aspects.

[0062] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements a method for running an application across systems as described in any one of the first aspects.

[0063] Fifthly, a computer program product is provided that, when run on an electronic device, causes the electronic device to implement a method for running an application across systems as described in any one of the first aspects.

[0064] In a sixth aspect, a chip system is provided, the chip system including a memory and a processor, the processor executing a computer program stored in the memory to implement a method for running an application across systems as described in any one aspect.

[0065] It is understood that the beneficial effects of the second to sixth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0066] Figure 1 A system architecture diagram of a software system mounted on a terminal device is provided as an embodiment of this application;

[0067] Figure 2 A signaling interaction diagram between an Android system and a Linux system is provided as an embodiment of this application;

[0068] Figure 3 A schematic flowchart illustrating a method for running an application across systems, provided as an embodiment of this application;

[0069] Figure 4 This is a schematic diagram of the interface of a terminal device provided in an embodiment of this application;

[0070] Figure 5A A schematic diagram illustrating how a terminal device refreshes its interface based on an input event, as provided in an embodiment of this application.

[0071] Figure 5B This is a schematic diagram illustrating how a terminal device refreshes its interface based on an input event, as provided in an embodiment of this application.

[0072] Figure 5C This is a schematic diagram illustrating how a terminal device refreshes its interface based on an input event, as provided in an embodiment of this application.

[0073] Figure 5D A schematic diagram illustrating how a terminal device refreshes its interface based on an input event, as provided in an embodiment of this application.

[0074] Figure 5E A schematic diagram illustrating how a terminal device refreshes its interface based on an input event, as provided in an embodiment of this application.

[0075] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0076] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limiting purposes, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details.

[0077] The terminology used in the following embodiments is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “the,” “the,” and “the” are intended to also include expressions such as “one or more,” unless the context clearly indicates otherwise.

[0078] There are many types of terminal devices, each applicable to different scenarios, and each type can run different software systems. When a terminal device is used in a specific scenario, it can run applications tailored to that scenario based on the software system it runs.

[0079] For example, when the terminal device is a desktop computer or laptop, it can be equipped with a Windows or Linux system and run office applications for use in office scenarios; when the terminal device is a mobile phone or tablet, it can be equipped with an Android system and run instant messaging applications for use in instant messaging scenarios.

[0080] To enable terminal devices to be used in more scenarios, developers can create different versions of the same application to match different software systems. This allows multiple terminal devices running different software systems to run the application corresponding to that scenario in the same situation, thus expanding the application scenarios of the terminal devices.

[0081] For example, in an office setting, desktop or laptop computers can run Windows or Linux systems and open office applications. After developing office applications compatible with the Android system, Android phones or tablets can also open these applications and use them in office settings, thus expanding the application scenarios for phones or tablets.

[0082] However, due to the hardware limitations of terminal devices, different types of terminal devices have different computing capabilities and display screen sizes. In the process of developing applications that match various software systems, it is also necessary to adjust the functions and interfaces of the applications in combination with the terminal devices corresponding to each software system, so as to obtain an application that matches both the hardware and software systems of the terminal devices.

[0083] Correspondingly, when running the same application, different types of terminal devices will display different application interfaces, and the functions provided by the applications running on different types of terminal devices will also differ to some extent.

[0084] For example, in an office setting, office applications running on desktop or laptop computers have a larger display interface and offer richer software features compared to office applications running on mobile phones or tablets, thus simplifying the steps of using office applications.

[0085] Therefore, this application proposes a method for running applications across systems. A terminal device, while running a first software system, runs a second software system via a virtual machine or container, and then runs applications through the second software system. The terminal device can also display the applications running in the second software system within the interface of the first software system, thereby providing users with applications that cannot run on the first software system, or applications whose functionality is missing when running on the first software system, thus enabling cross-system application execution.

[0086] The following example illustrates the software system architecture of a terminal device that runs on Android and uses a container to run Linux.

[0087] Figure 1 This application provides a system architecture diagram of a software system mounted on a terminal device, where the first software system of the terminal device is an Android system and the second software system is a Linux system. Figure 1 As shown, both Android and Linux systems use the Linux kernel. Furthermore, Android can include an application framework layer and an application layer; Linux includes a window service (Weston) and multiple applications.

[0088] The application framework layer of the Android system can include: Input Manager Service (IMS), Activity Manager Service (AMS), Window Manager Service (WMS), and the system service Surface Flinger. IMS manages input operations detected by the terminal device, AMS manages the activities of various applications, WMS manages the windows of various applications, and the system service Surface Flinger is responsible for composing all display layers of the Android system.

[0089] It should be noted that the Android system of the terminal device may also include Figure 1The hardware abstraction layer and system runtime libraries are not shown in the figure. The system runtime libraries may include: Android runtime libraries, which may include core libraries and virtual machines. The system runtime libraries may also include: C libraries or C++ libraries, which will not be elaborated here.

[0090] Furthermore, the multiple applications on a Linux system can include multiple X11 applications (X11 APPs) and multiple Wayland applications (wayland apps). Among them, X11 applications are those compatible with the older version of the X11 protocol, and Wayland applications are those compatible with the newer version of the Wayland protocol.

[0091] Additionally, Weston for Linux systems can include: a desktop-shell system interface manager, an application compatibility protocol (xwayland), a compositor, and a compositor backend. The desktop-shell system interface manager manages the global interface of the Linux system; the application compatibility protocol ensures compatibility with various X11 applications while maintaining compatibility with individual Wayland applications; the compositor combines the various layers of an application to create the final interface; and the compositor backend processes the finalized interface.

[0092] When a terminal device runs an application across systems, it can enable a proxy Android application package (APK) in the Android system. The Android system then interacts with the Linux system through the proxy APK, displaying the application running in the Linux system that corresponds to the proxy APK.

[0093] Further, see Figure 1 , Figure 1 The document also illustrates the software architecture of the proxy APK, such as... Figure 1 As shown, the proxy APK software architecture can include: a communication layer (native), a management layer (myservice), and an activity layer (activity).

[0094] The native component acts as a communication channel between the APK and the Linux system, transmitting information to and receiving feedback from the Linux system. For example, the native component can send startup signals to the Linux system to launch applications located on the Linux system, send detected input events to the Linux system, and receive window display information (such as refreshing the displayed interface) or window management information (such as adjusting the display size or position) from the Linux system.

[0095] `myservice` is used to determine the corresponding app activity from multiple app activities based on information from the Linux system. It then forwards this information to the determined app activity, allowing it to refresh its interface or adjust its window accordingly. Furthermore, `myservice` can also create or destroy app activities based on the Linux system's feedback, thus managing app activities.

[0096] An activity can include a main activity and an app activity. The main activity is the main program of the proxy APK, used to launch the proxy APK. The app activity can be the activity corresponding to the application running on the Linux system. For example, after the Linux system launches the application based on the proxy APK, the proxy APK can create an app activity corresponding to the application within the proxy APK based on the information fed back by the Linux system.

[0097] Each app activity can collect triggered input events and send the collected input events to the Linux system through myservice and native. It can also receive information from the Linux system based on the input events through native and then refresh the currently displayed interface of the app activity (such as displaying a floating box, blinking icons, and changing colors) or adjust the window displayed by the app activity (such as adjusting the size or position of the window) based on the information from the Linux system.

[0098] See Figure 2 The following example uses a tablet computer in an office setting to illustrate the signaling interaction process between an Android and Linux system on a tablet computer when running office applications. The tablet computer can connect to a keyboard and mouse to receive input events triggered by these devices.

[0099] like Figure 2 As shown, the signaling interaction process between the Android system and the Linux system on a tablet computer may include the following steps:

[0100] S201. After the tablet computer detects the user's activation operation triggered by the proxy APK, it can start the main activity of the proxy APK.

[0101] S202, the proxy APK can send the launcher of office applications to the Linux system via native methods. Figure 2 The signaling (represented by app1) can also send the storage path and name of office applications in the Linux system to the Linux system.

[0102] S203: The Linux system can launch office applications based on the received signaling, according to the storage path and name of the corresponding office applications. Correspondingly, the office applications can request a window from Weston, and then draw the window according to the one allocated by Weston to obtain the interface of the office application.

[0103] S204. Office applications can send their interface to Weston. Weston then sends the office application's interface, the signaling for creating the corresponding appactivity, and the window information allocated by Weston for the office application to the proxy APK in the Android system. The window information may include window identifier, window size, and window position.

[0104] S205. The proxy APK can receive information from the Linux system via native methods and forward it to myservice. Based on the signaling from Linux, the proxy APK can create an appactivity corresponding to the proxy APK through myservice and forward the received office application interface to that appactivity, causing the appactivity to display the corresponding office application interface.

[0105] Furthermore, the proxy APK can also use myservice to combine the window information fed back by Linux to establish an association between the window identifier in the window information and the established app activity. So that when it receives information fed back by the Linux system again, myservice can determine the app activity corresponding to the window identifier based on this association, and then forward the information fed back by the Linux system to the app activity.

[0106] S206. When the app activity corresponding to an office application is in the foreground, the app activity can collect the input events triggered by the Android system.

[0107] S207. Send the collected input events to the Linux system through the proxy APK's myservice and native methods.

[0108] Weston on S208 and Linux systems can relay the input event to office applications, which then redraw their interface based on the input event, resulting in a refreshed interface.

[0109] S209. Office applications can send the refreshed interface to Weston, and Weston can send the refreshed interface back to the proxy APK, along with the window information corresponding to the office application.

[0110] S210: The proxy APK can receive the refreshed interface and window information through native, and use myservice to find the app activity corresponding to the window identifier in the window information. Then, it forwards the refreshed interface to the found app activity, so that the app activity can display the refreshed interface.

[0111] It should be noted that if the tablet detects a triggered action to close office applications, it can also use a similar process to close office applications in the Linux system and stop displaying the office application interface in the Android system.

[0112] Furthermore, the above example only illustrates how to display office applications running on a Linux system within an Android system. In practical applications, Android systems can also simultaneously display other applications running on a Linux system. Figure 2 The Sino-Israeli app2 indicates that Figure 2 For app2, similar steps to those described in S201-S210 can also be performed. The process of displaying other applications in the Android system is similar to the process of displaying office applications, and will not be repeated here.

[0113] Figure 3 This is a schematic flowchart illustrating a method for running an application across systems, provided in an embodiment of this application. It is intended as an example and not a limitation. This method can be applied to the terminal device described above, which runs a second software system via a virtual machine or container within a first software system. See also... Figure 3 The method includes:

[0114] Step 301: Launch the proxy APK in the first software system and create the main activity.

[0115] To enable the same terminal device to be used in more scenarios, in addition to the first software system, the terminal device can be equipped with a second software system through a virtual machine or container. This allows different applications to run through the first and second software systems respectively, in order to adapt to different scenarios.

[0116] In practical applications, terminal devices can run different software systems, resulting in various combinations of the first and second software systems. This application uses Android as the first software system and Linux as the second software system as an example to illustrate the process of a terminal device running applications across systems.

[0117] Android and Linux systems can run different applications to suit different scenarios. Correspondingly, during operation, a terminal device can launch different applications on different software systems depending on the scenario. If the current scenario requires running an application on the Android system, the terminal device can run the application on the Android system based on the triggered operation.

[0118] If the current scenario requires running an application on a Linux system, the terminal device can launch the proxy APK based on the operation triggered by the proxy APK in the corresponding Android system interface, and call the Android System's AMS to establish the main activity corresponding to the proxy APK.

[0119] It should be noted that the terminal device can launch the proxy APK in different ways. For example, the terminal device can launch the proxy APK based on a click triggered by the detected icon of the proxy APK, or based on an input command prompt, or based on other triggered operations. This application embodiment does not limit the method of launching the proxy APK.

[0120] If the terminal device launches the proxy APK by clicking its icon, it means that the terminal device can generate the proxy APK icon in the Android system and launch the proxy APK by clicking its icon.

[0121] Furthermore, a terminal device can generate one or more proxy APK icons in the Android system, allowing one or more applications to run in the Linux system via these proxy APK icons. If the terminal device generates only one proxy APK icon, that icon can correspond to multiple applications in the Linux system; if the terminal device creates multiple proxy APK icons, each proxy APK icon can correspond one-to-one with each application in the Linux system.

[0122] Step 302: In the first software system, the startup information is transmitted to the second software system through the proxy APK's native method.

[0123] The startup information may include startup signaling for starting a target application located on a Linux system, and may also include the storage path and application identifier of the target application. The storage path of the target application is the storage space where the application is located in the Linux system, and the application identifier of the target application may be the application's name, identity (ID), or other information used to uniquely identify the target application. This application embodiment does not limit the storage path and application identifier.

[0124] In one optional embodiment, after the terminal device enables the proxy APK in the Android system, it can generate startup signaling through the main activity of the proxy APK and obtain the storage path and application identifier of the target application, thereby combining them to obtain startup information. Then, the proxy APK can send this startup information to the Linux system via native methods, so that the Linux system can run the target application according to the startup information.

[0125] For example, if the terminal device is currently used in an office scenario, it needs to run an office application on the Linux system and display the corresponding interface of that office application on the Android system. Accordingly, after the terminal device launches the proxy APK on the Android system, it can send startup information to the Linux system through the proxy APK. This startup information may include signaling instructing the Linux system to launch the office application, or it may include the storage path and application identifier of the office application on the Linux system.

[0126] Step 303: The second software system starts the target application based on the received startup information.

[0127] Corresponding to step 302, the Linux system can receive the startup information sent by the proxy APK and extract the data from the startup information to obtain the startup signaling, the storage path of the target application, and the application identifier. The Linux system can then start the target application based on the startup signaling, combined with the storage path and application identifier of the target application.

[0128] Step 304: The second software system obtains the interface of the target application and forwards the interface of the target application to the proxy APK.

[0129] After the Linux system runs the target application based on the boot information, the target application can automatically draw its interface based on its resources and send the interface to Weston on the Linux system. Weston can then forward the target application's interface to the proxy APK in the Android system.

[0130] During the process of rendering the target application's interface, the target application can first request a window from Weston, and Weston can then allocate a window to the target application based on the configured data. Afterwards, the target application can render its interface within the allocated window, using its available resources.

[0131] The window assigned by Weston can have information such as window identifier, window size, and window position. The window identifier is used to uniquely identify the window, the window size is used to indicate the size of the window, and the window position is used to indicate the position where the window is displayed.

[0132] In addition, when Weston forwards the target application's interface to the proxy APK, it can also carry the creation signaling for creating the appactivity and the window information of the window allocated by Weston. This window information may include window identifier, window size, and window position, etc.

[0133] It should be noted that in practical applications, the interface drawn by an application may include one or more layers. When multiple layers are included, Weston's compositor can combine the layers based on their stacking relationships and transparency to obtain the composited interface. However, for the sake of simplicity, this embodiment of the application uses an example where the target application's interface includes one layer; this embodiment does not limit the number of layers included in the target application's interface.

[0134] Step 305: The proxy APK displays the target application's interface in the first software system.

[0135] In the Android system, the proxy APK can not only send signals to the Linux system to launch the target application, but also receive feedback from the Linux system about the interface generated by the target application. This allows the target application's interface to be displayed in the Android system, enabling cross-system display of the application's interface.

[0136] Specifically, the proxy APK can receive feedback from the Linux system regarding the target application's interface via the native API. It can also receive window information and creation signals from the Linux system. Based on the creation signals, the proxy APK can invoke the Android System's AMS to create an app activity corresponding to the target application. It then inputs the target application's interface into the created app activity, combining this with information such as window size and position from the window information, thereby displaying the target application's interface on the Android system.

[0137] It should be noted that in practical applications, the proxy APK can create app activities corresponding to each application running on the Linux system in the Android system; that is, it can create one or more app activities in the Android system. This embodiment only illustrates the creation of one app activity and does not limit the number of app activities created by the proxy APK in the Android system.

[0138] It should also be noted that if the interface of the application received by the proxy APK includes multiple layers, the proxy APK can call the Android system's Surface flinger to coordinate the multiple layers, thereby obtaining an interface consistent with the target application running on the Linux system.

[0139] Furthermore, the interface of the target application displayed in the Android system is the same image as the interface of the target application displayed in the Linux system; that is, the image displayed in the Android system is consistent with the interface of the target application.

[0140] Step 306: For the target application's window identifier and corresponding app activity, the proxy APK establishes the mapping relationship between the window identifier and the app activity.

[0141] After creating the app activity corresponding to the target application, the proxy APK can establish a correspondence between the app activity and the window identifier in the window information by using the proxy APK's myservice. In subsequent steps, the proxy APK can use this correspondence to find the app activity corresponding to the target application from multiple app activities, thereby updating and displaying the refreshed interface of the target application in the Android system.

[0142] It should be noted that the embodiments of this application illustrate the example of first displaying the interface of the target application and then establishing the correspondence between the appactivity and the window identifier. In practical applications, the correspondence between the appactivity and the window identifier can also be established first, and then the interface of the target application can be displayed in the appactivity. Alternatively, the interface of the target application can be displayed at the same time as establishing the correspondence. The embodiments of this application do not limit the order of establishing the correspondence and displaying the interface of the target application after establishing the appactivity.

[0143] Step 307: The proxy APK sends feedback to the second software system on the input events triggered by the target application detected in the first software system.

[0144] Among them, input events are used to represent input operations triggered by the user on the terminal device, which are collected by the terminal device.

[0145] After displaying the interface corresponding to the target application, the Android system can refresh the displayed interface based on the input events triggered by the user, thereby enabling interaction between the user and the target application running on the Linux system, so that the displayed interface corresponding to the application can be continuously updated according to the user's actions.

[0146] Furthermore, the terminal device can display multiple interfaces to the user in the Android system. Some of these interfaces can be the interfaces corresponding to applications running on the Android system, while the other interfaces can be the interfaces corresponding to applications running on the Linux system.

[0147] Accordingly, when a terminal device collects an input event, the currently focused interface of the Android system may be the interface corresponding to an application running on the Android system, or it may be the interface corresponding to an application running on the Linux system. The terminal device can use different methods in conjunction with the input event to refresh the currently focused interface depending on the interface being focused on.

[0148] Specifically, if the Android system is currently focused on the interface corresponding to the target application running on the Linux system, the terminal device can collect input events through the Android system's IMS and send the collected input events to the WMS. The WMS can then forward the collected input events to the app activity corresponding to the target application. The app activity corresponding to the target application can forward the collected input events to the Linux system through myservice and native, respectively, so that the target application on the Linux system can generate a refreshed interface based on the input events.

[0149] If the input event is mouse input or touch screen input, it can also correspond to location information, indicating the location on the terminal device's screen where the input event was triggered. For example, this location information can be coordinate information.

[0150] Furthermore, input events can include various types of input operations, such as key input operations triggered by the keyboard, mouse input operations such as clicking, dragging or swiping triggered by the mouse, and touch screen input operations such as clicking, dragging or swiping triggered by the touch screen. This application embodiment does not limit the type of input event.

[0151] Before the proxy APK reports input events to the Linux system, it can first determine the type of input event. If the type of input event is key input and the Android system is currently focused on the interface corresponding to the target application, then the proxy APK can report the collected input events to the Linux system.

[0152] If the input event is of mouse or touch type, the Android system can first determine the interface corresponding to the input event based on the coordinates of the input event and the stacking relationship between various interfaces in the Android system, and then focus on the determined interface. If the interface corresponds to the target application, the proxy APK can report the input event to the Linux system.

[0153] For example, see Figure 4 , Figure 4 The image shows interface A and interface B displayed on a terminal device within the Android system. Interface A corresponds to an application running on the Android system, while interface B corresponds to an application running on the Linux system. Currently, the Android system is focused on interface A. If an input event of mouse or touch type is detected in a certain area of ​​interface B, the Android system determines that the input event corresponds to interface B. Therefore, the Android system can focus on interface B, that is, bring interface B to the foreground of the Android system, and report the input event to the Linux system through a proxy APK.

[0154] Step 308: The second software system sends the input event back to the target application and obtains the interface refreshed by the target application based on the input event.

[0155] After receiving an input event from the proxy APK, the Linux system can send the input event back to the target application. This allows the target application to refresh its interface based on the input event, so that the Android system can display the refreshed interface in subsequent steps.

[0156] Specifically, the Linux system can receive input events triggered by the target application in the Android system through Weston, and map the input events to the target application. The target application can then refresh the currently displayed interface based on the mapped input events to obtain the refreshed interface.

[0157] Furthermore, similar to step 307, the Android system can collect different types of input operations and also report different types of input operations back to the Linux system. Correspondingly, when the Linux system receives different types of operations, it can also use a similar method to step 307 to map and report back to the target application.

[0158] For example, when multiple applications are running on a Linux system, if the target application is in the foreground of the Linux system and receives a key input event in the Linux system, the Linux system can send feedback on the input event to the target application, and the target application can refresh the currently displayed interface based on the input event.

[0159] If the target application is running in the background of the Linux system, and the Linux system receives an input event of either mouse or touch input type, the Linux system can determine the application corresponding to the input operation based on the location information of the input event and the layering relationship between the interfaces of various applications in the Linux system. If the input operation corresponds to the target application, the Linux system can bring the target application to the foreground, that is, the Linux system focuses on the target application's interface.

[0160] It should be noted that the process by which the target application refreshes the currently displayed interface based on the input event to obtain the refreshed interface can refer to existing technologies, and this application embodiment does not limit this process.

[0161] Step 309: The second software system sends the refreshed interface back to the proxy APK.

[0162] Similar to step 304, after the target application refreshes the interface, it can send the refreshed interface to Weston on the Linux system. Weston can then send the refreshed interface and window information to the proxy APK. This step will not be described in detail here.

[0163] Step 310: The proxy APK refreshes the interface corresponding to the target application in the first software system based on the received refreshed interface.

[0164] After the proxy APK sends the collected input events back to the Linux system, it can receive the refreshed interface sent by the Linux system and replace the interface of the current target application in the Android system according to the refreshed interface, thus enabling cross-system application execution.

[0165] In one optional embodiment, the proxy APK can receive refreshed interface and window information from the Linux system via the native side. The native side can then forward the refreshed interface and window information to the proxy APK's myservice. Based on the window identifier in the window information and the correspondence established in step 306, the myservice determines the app activity corresponding to the window identifier and sends the refreshed interface to that app activity, allowing the app activity to replace the currently displayed interface with the refreshed interface.

[0166] For example, Figure 5A , Figure 5B , Figure 5C , Figure 5D and Figure 5E The process of updating the interface of the target application in the Android system based on different input events triggered by the terminal device is illustrated below. The interface changes corresponding to different input events are described in detail below:

[0167] like Figure 5A As shown, in the Android system, the terminal device launches the proxy APK in response to clicking its icon. The target application runs on the Linux system through the proxy APK, and the interface corresponding to the target application is displayed on the Android system through the proxy APK.

[0168] like Figure 5BAs shown, after the terminal device displays the interface corresponding to the target application, the user may need to adjust the position of the displayed interface. The Android system on the terminal device can detect press and swipe operations triggered on the title bar area of ​​the interface and forward these operations, along with their corresponding coordinates, to the Linux system via a proxy APK. Correspondingly, the Linux system can send back the received operations and their corresponding coordinates to the target application. Based on these coordinates, the target application can determine that the press and swipe operations correspond to the title bar of the interface and that they are used to adjust the position of the target application's interface. It can then send this information back to Weston in the Linux system. Weston can then adjust the position of the target application's interface based on the press and swipe operations. Weston can also forward this information to the proxy APK, instructing the Android system to adjust the position of the target application's interface within the Android system based on the press and swipe operations, thus displaying the process of adjusting the interface position within the Android system.

[0169] and Figure 5B The process of forwarding APK data to the Linux system via a proxy is similar to the input operations collected in the Android system, such as... Figure 5C As shown, the terminal device can also collect triggered operations in the Android system and forward the collected input operations to the Linux system through a proxy APK. The Linux system feeds back the received input operations to the target application, thereby adjusting the size of the target application's interface and continuously refreshing the target application's interface during the adjustment process. It then feeds back the continuously refreshed target application's interface to the proxy APK. The Android system can then refresh the corresponding interface of the target application in the Android system based on the interface received by the proxy APK, thus displaying the process of adjusting the interface size in the Android system.

[0170] and Figure 5C The process of forwarding APK data to the Linux system via a proxy is similar to the input operations collected in the Android system, such as... Figure 5D As shown, when the Android system detects a typed input, it can also send feedback to the Linux system via a proxy APK. The Linux system, similar to the process of resizing the interface, can add information corresponding to the typed input to the target application, continuously refreshing the target application's interface and sending this refreshed interface back to the proxy APK. The Android system, in a similar manner to the interface resizing process, continuously displays information corresponding to the typed input on the interface, thus showcasing the typing process within the Android system.

[0171] like Figure 5E As shown, when a user wants to close a target application, they can trigger a close operation on the close option in the target application's corresponding interface within the Android system. Correspondingly, the terminal device can collect the triggered input operation and its corresponding coordinates within the Android system—that is, a click operation triggered at a certain location—and forward this input operation and its corresponding coordinates to the Linux system. The Linux system can then provide feedback to the target application based on this input operation and its corresponding coordinates. The target application can determine the area corresponding to the close option based on these coordinates, and combined with the click operation, determine to close the target application, thereby terminating the target application's process and ceasing to display its interface. Weston can then send a command to the proxy APK to destroy the corresponding app activity. The proxy APK can then destroy the target application's corresponding app activity based on the window identifier, ceasing to display the target application's interface.

[0172] In summary, the method for running applications across systems provided in this application displays a first interface of the target application in a first software system and replaces the first interface with a refreshed second interface based on input events. This allows for seamless display of the target application running in the second software system within the first software system without requiring the target application to be run in the first system. This avoids discrepancies between different versions of the target application that are compatible with different software systems. Furthermore, based on input events collected by the first software system, the interface of the target application can be refreshed within the first software system, enabling interaction between the user and the target application running in the second software system. This improves the diversity of applications that can be run on a terminal device and enhances the adaptability of the terminal device to different scenarios.

[0173] Furthermore, by using a proxy APK, one or more app activities can be created in the first software system. By combining these one or more app activities, the interfaces of one or more applications running in the second software system can be displayed simultaneously in the first software system, which can further improve the adaptability and versatility of terminal device applications in different scenarios.

[0174] In addition, by establishing a correspondence between the window identifiers of the app activity and the target application, the time required to refresh the target application's interface in the first software system can be reduced, and the synchronization of window management and lifecycle between the app activity and the target application can be achieved.

[0175] Furthermore, by collecting input events based on the window currently in the foreground in the first software system, if the window currently in the foreground is the window corresponding to the target application, the first software system can send the collected input events back to the second software system, obtain and display the interface redrawn by the target application based on the input events, which can solve the input problems and misoperation problems triggered by the target application in the first software system, and improve the accuracy of collecting input events for the target application.

[0176] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0177] Corresponding to the method for running applications across systems described in the above embodiments, this application also provides an apparatus for running applications across systems, which has the functions described above. Figures 1 to 5E The functionality of any of the methods corresponding to cross-system application execution will not be elaborated here.

[0178] The following describes the electronic device involved in the embodiments of this application. Please refer to... Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0179] The electronic device may include a processor 610, an external memory interface 620, an internal memory 621, a universal serial bus (USB) interface 630, a charging management module 640, a power management module 641, a battery 642, antenna 1, antenna 2, a mobile communication module 650, a wireless communication module 660, an audio module 670, a speaker 670A, a receiver 670B, a microphone 670C, a headphone jack 670D, a sensor module 680, buttons 690, a motor 691, an indicator 692, a camera 693, a display screen 694, and a subscriber identification module (SIM) card interface 695, etc. The sensor module 680 may include a pressure sensor 680A, a gyroscope sensor 680B, a barometric pressure sensor 680C, a magnetic sensor 680D, an accelerometer sensor 680E, a distance sensor 680F, a proximity light sensor 680G, a fingerprint sensor 680H, a temperature sensor 680J, a touch sensor 680K, an ambient light sensor 680L, a bone conduction sensor 680M, etc.

[0180] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0181] The processor 610 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0182] The controller can serve as the nerve center and command center of an electronic device. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0183] The processor 610 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 610 is a cache memory. This memory can store instructions or data that the processor 610 has just used or that are used repeatedly. If the processor 610 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 610, and thus improves the efficiency of the system.

[0184] In some embodiments, the processor 610 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0185] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 610 may include multiple I2C buses. The processor 610 can couple to the touch sensor 680K, charger, flash, camera 693, etc., through different I2C bus interfaces. For example, the processor 610 can couple to the touch sensor 680K through the I2C interface, enabling the processor 610 and the touch sensor 680K to communicate through the I2C bus interface, thus realizing the touch function of the electronic device.

[0186] The I2S interface can be used for audio communication. In some embodiments, the processor 610 may include multiple I2S buses. The processor 610 can be coupled to the audio module 670 via the I2S bus to enable communication between the processor 610 and the audio module 670. In some embodiments, the audio module 670 can transmit audio signals to the wireless communication module 660 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0187] The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 670 and the wireless communication module 660 can be coupled via the PCM bus interface. In some embodiments, the audio module 670 can also transmit audio signals to the wireless communication module 660 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0188] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 610 and the wireless communication module 660. For example, the processor 610 communicates with the Bluetooth module in the wireless communication module 660 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 670 can transmit audio signals to the wireless communication module 660 via the UART interface to enable music playback through Bluetooth headphones.

[0189] The MIPI interface can be used to connect the processor 610 to peripheral devices such as the display screen 694 and the camera 693. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 610 and the camera 693 communicate via the CSI interface to enable the electronic device's shooting function. The processor 610 and the display screen 694 communicate via the DSI interface to enable the electronic device's display function.

[0190] The GPIO interface is configurable via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 610 to a camera 693, a display screen 694, a wireless communication module 660, an audio module 670, a sensor module 680, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0191] The USB 630 interface is a USB standard compliant interface, which can be a Mini USB interface, Micro USB interface, USB Type-C interface, etc. The USB 630 interface can be used to connect a charger to charge electronic devices, and can also be used for data transfer between electronic devices and peripherals. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0192] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a limitation on the structure of the electronic device. In other embodiments of this application, the electronic device may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0193] The wireless communication function of electronic devices can be implemented through antenna 1, antenna 2, mobile communication module 650, wireless communication module 660, modem processor, and baseband processor.

[0194] Electronic devices implement display functions through a GPU, a display screen 694, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 694 and the application processor. The GPU performs mathematical and geometric calculations and is used for graphics rendering. The processor 610 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0195] Display screen 694 is used to display images, videos, etc. Display screen 694 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device may include one or N displays 694, where N is a positive integer greater than 1.

[0196] Electronic devices can achieve shooting functions through ISP, camera 693, video codec, GPU, display 694 and application processor.

[0197] The ISP (Image Signal Processor) is used to process data fed back from the camera 693. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 693.

[0198] Camera 693 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device may include one or N cameras 693, where N is a positive integer greater than 1.

[0199] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when an electronic device is selecting a frequency, a DSP can perform a Fourier transform on the frequency energy.

[0200] Video codecs are used to compress or decompress digital video. Electronic devices can support one or more video codecs. This allows the electronic device to play or record video in various encoded formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0201] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0202] The external storage interface 620 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with the processor 610 through the external storage interface 620 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0203] Internal memory 621 can be used to store computer executable program code, which includes instructions. Processor 610 executes various functional applications and data processing of the electronic device by running the instructions stored in internal memory 621. Internal memory 621 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the electronic device (such as audio data, phonebook, etc.). Furthermore, internal memory 621 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0204] Pressure sensor 680A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 680A can be disposed on display screen 694. There are many types of pressure sensors 680A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 680A, the capacitance between the electrodes changes. The electronic device determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 694, the electronic device detects the intensity of the touch operation based on pressure sensor 680A. The electronic device can also calculate the touch position based on the detection signal from pressure sensor 680A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands. For example, when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS is executed.

[0205] The gyroscope sensor 680B can be used to determine the motion attitude of an electronic device. In some embodiments, the gyroscope sensor 680B can determine the angular velocity of the electronic device around three axes (i.e., the x, y, and z axes). The gyroscope sensor 680B can be used for image stabilization. For example, when the shutter is pressed, the gyroscope sensor 680B detects the angle of the electronic device's shake, calculates the distance that the lens module needs to compensate based on the angle, and allows the lens to counteract the shake of the electronic device by moving in the opposite direction, thus achieving image stabilization. The gyroscope sensor 680B can also be used in navigation and motion-sensing gaming scenarios.

[0206] Touch sensor 680K, also known as a "touch panel," can be located on display screen 694. The touch sensor 680K and display screen 694 together form a touchscreen, also known as a "touchscreen." Touch sensor 680K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 694. In other embodiments, touch sensor 680K may also be located on the surface of the electronic device, in a different position than display screen 694.

[0207] Buttons 690 include a power button, volume buttons, etc. Buttons 690 can be mechanical buttons or touch-sensitive buttons. The electronic device can receive button input and generate key signal inputs related to user settings and function control.

[0208] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0209] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0210] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0211] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0212] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0213] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0214] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to an electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0215] Finally, it should be noted that the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for running applications across systems, characterized in that, Applied to an electronic device, the electronic device carrying a first software system and a second software system, the second software system running based on the first software system, the method includes: Through the proxy APK in the first software system, an application activity corresponding to the target application is created in the first software system, and the first interface of the target application is displayed in the first software system through the application activity, while the target application runs in the second software system; The second software system feeds back an input event to the target application, thereby obtaining a refreshed second interface of the target application. The input event is triggered in the first software system for the first interface. Replace the first interface in the first software system with the second interface.

2. The method according to claim 1, characterized in that, The first software system is the Android system, and the second software system is the Linux system.

3. The method according to claim 1 or 2, characterized in that, Before displaying the first interface of the target application in the first software system, the method further includes: Send startup information from the first software system to the second software system; The target application is launched in the second software system according to the startup information, and the first interface is obtained.

4. The method according to claim 3, characterized in that, The step of sending startup information from the first software system to the second software system includes: Based on the operation triggered in the first software system, the proxy Android application package APK is launched in the first software system; The startup information is composed of the startup signaling obtained through the main activity of the proxy APK, the storage path of the target application, and the application identifier of the target application; The startup information is sent from the first software system to the second software system through the management and communication layers of the proxy APK.

5. The method according to claim 3, characterized in that, The startup information includes: startup signaling, the storage path of the target application, and the application identifier of the target application; The step of launching the target application in the second software system according to the startup information to obtain the first interface includes: The second software system locates the target application based on the startup signaling, combined with the storage path and application identifier of the target application; Launch the target application to obtain the first interface generated by the target application.

6. The method according to claim 5, characterized in that, The step of launching the target application and obtaining the first interface generated by the target application includes: The target application requests a window from the window service of the second software system and obtains the window allocated to the target application by the window service; The target application draws the first interface based on the window allocated by the window service and in conjunction with the resources of the target application.

7. The method according to any one of claims 1-2 and 4-6, characterized in that, The step of creating an app activity corresponding to the target application in the first software system through a proxy APK in the first software system, and displaying the first interface of the target application in the first software system through the app activity, includes: The first software system receives the first interface, window information, and creation signaling sent by the second software system through window services via a proxy APK. The window information is used to represent the information of the window allocated by the window service of the second software system to the target application. The proxy APK, based on the creation signaling and in conjunction with the Activity Management Service (AMS) of the first software system, creates an application activity corresponding to the target application in the first software system. The proxy APK displays the first interface in the first software system through the application activity, combined with the first interface and the window information.

8. The method according to claim 7, characterized in that, The window information includes the window identifier corresponding to the target application; Before the second software system feeds back the input event to the target application and obtains the refreshed second interface of the target application, the method further includes: The proxy APK establishes a correspondence between the window identifier corresponding to the target application and the application activity corresponding to the target application through the management layer.

9. The method according to any one of claims 1-2, 4-6 and 8, characterized in that, Before the second software system feeds back the input event to the target application and obtains the refreshed second interface of the target application, the method further includes: The input events triggered are collected in the first software system; The input events are fed back from the first software system to the second software system through the proxy APK.

10. The method according to claim 9, characterized in that, The input events collected and triggered in the first software system include: The input events are collected through the Input Management Service (IMS) of the first software system; The input event is forwarded to the application activity corresponding to the target application through the Window Management Service (WMS) of the first software system.

11. The method according to claim 9, characterized in that, The step of feeding back the input event from the first software system to the second software system via the proxy APK includes: The proxy APK feeds back the input events received by the application activity corresponding to the target application to the second software system through the management layer and the communication layer.

12. The method according to claim 9, characterized in that, The input events collected and triggered in the first software system include: Obtain the input type of the input event and the stacking relationship between windows in the first software system; If the input type of the input event is key input and the window corresponding to the target application is in the foreground, then the input event is collected; If the input type of the input event is mouse input or touch screen input, then the window corresponding to the input event is determined based on the position of the input event and the stacking relationship between windows in the first software system. If the window corresponding to the input event is the window corresponding to the target application, then the input event is collected.

13. The method according to any one of claims 1-2, 4-6, 8 and 10-12, characterized in that, The step of feeding back input events to the target application through the second software system to obtain the refreshed second interface of the target application includes: The input event is received through the window service of the second software system, and the input event is mapped to the target application. The target application redraws its interface based on the mapped input events to obtain the second interface.

14. The method according to any one of claims 1-2, 4-6, 8 and 10-12, characterized in that, The step of replacing the first interface in the first software system with the second interface includes: The window service of the second software system provides feedback on the window information of the second interface and the target application to the proxy APK. The proxy APK replaces the first interface corresponding to the target application in the first software system with the second interface based on the second interface and the window information of the target application.

15. The method according to claim 14, characterized in that, The proxy APK replaces the first interface corresponding to the target application in the first software system with the second interface based on the second interface and the window information of the target application, including: The proxy APK receives window information from the second interface and the target application through the communication layer; The proxy APK, through the management layer, searches for the application activity corresponding to the window information based on the correspondence between the window identifier corresponding to the target application and the application activity corresponding to the target application. The proxy APK sends the second interface to the application activity corresponding to the window information through the management layer, replacing the first interface with the second interface.

16. The method according to any one of claims 1-2, 4-6, 8, 10-12, and 15, characterized in that, The input events include: window size adjustment operations, window position adjustment operations, and window function interaction operations.

17. An electronic device, characterized in that, include: A processor for running a computer program stored in a memory, such that the electronic device implements the method of running an application across systems as described in any one of claims 1 to 16.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of running an application across systems as described in any one of claims 1 to 16.

19. A computer program product, characterized in that, When a computer program product is run on an electronic device, the electronic device enables the method of running an application across systems as described in any one of claims 1 to 16.

20. A chip system, characterized in that, The chip system includes a memory and a processor, the processor executing a computer program stored in the memory to implement a method for running an application across systems as described in any one of claims 1 to 16.

Images