WO2017167126A1

WO2017167126A1 - Window display method, information exchange method and system

Info

Publication number: WO2017167126A1
Application number: PCT/CN2017/078040
Authority: WO
Inventors: 王政华
Original assignee: 阿里巴巴集团控股有限公司; 王政华
Priority date: 2016-03-31
Filing date: 2017-03-24
Publication date: 2017-10-05
Also published as: CN107291319A

Abstract

Disclosed are a window display method, a control information exchange method and a system. An application management module (74) in a second subsystem sends control information to a first connection service component (71) in a first subsystem via a second connection service component (72) in the second subsystem, and sends the same control information to an application management module (73) in the first subsystem, enabling exchange of control information across operating systems. At the same time a window management module (61) in a second subsystem sends window information to a second graphics compositor (62) in the subsystem, the second graphics compositor (62) sends the window information to a first graphics compositor (63) in a first subsystem, the first graphics compositor (63) displays a window according to the window information received from the second graphics compositor (62) and window information in the first subsystem, enabling window-level merging of different operating systems.

Description

Window display method, information interaction method and system

Technical field

The present application relates to the field of communications technologies, and in particular, to a window display method, an information interaction method, and a system thereof.

Background technique

The cloud operating system, also known as cloud OS, is an operating system supported by cloud computing and cloud storage technologies. The cloud operating system will be widely used in the future because it can integrate massive computing power and provide powerful resource allocation capabilities.

Cloud operating systems can be used for both traditional desktop systems (such as PCs) and mobile devices. Applications or services based on cloud operating systems, as well as applications or services based on traditional operating systems, will operate within the framework of the cloud operating system, which requires the cloud operating system framework to integrate applications or services based on different operating systems.

At present, there is no corresponding solution for how to integrate applications or services based on different operating systems at the window level or at the control level within an operating system framework.

Application content

The embodiment of the present application provides a window display method and system for displaying an application window based on different operating systems.

A window display method provided by an embodiment of the present application includes:

The second graphics synthesizer receives window information sent by the window management module of the second subsystem, and the second graphics synthesizer is a graphics synthesizer in the second subsystem;

The second graphics synthesizer sends the window information to a first graphics synthesizer, the first graphics synthesizer being a graphics synthesizer in the first subsystem;

The first graphics synthesizer according to the window information received from the second graphics synthesizer and the The window information sent by the window management module in a subsystem is displayed.

Preferably, the first graphics synthesizer performs window display according to window display rules, according to window information received from the second graphics synthesizer and window information sent by the window management module in the first subsystem.

The window display rule includes one or any combination of the following rules:

Window focus setting rules;

Window position setting rules;

Window Z ordering rules.

The window focus setting rule includes the following rules: a focus setting priority corresponding to each window type.

Preferably, when the window display is performed according to the window position setting rule, the method includes:

Obtaining a window type and/or a window layout according to the window information;

The window is displayed according to the window type and/or window layout and window position setting rules.

Preferably, the window Z-ordering rule includes the following rules: a Z-ordering order corresponding to the various window types.

Preferably, the window information comprises one or any combination of the following:

Window type information;

Window status information;

Window layout information;

The window displays the attribute information.

Preferably, the first subsystem is a Host subsystem, and the second subsystem is a Guest subsystem.

A window display system provided by an embodiment of the present application includes:

a second graphics synthesizer, configured to receive window information sent by a window management module of the second subsystem, where the second graphics synthesizer is a graphics synthesizer in the second subsystem, and the window information is Sending to a first graphics synthesizer, the first graphics synthesizer being a graphics synthesizer in the first subsystem;

And a first graphics synthesizer configured to perform window display according to the window information received from the second graphics synthesizer and the window information sent by the window management module in the first subsystem.

Preferably, the first graphic synthesizer is specifically configured to:

According to the window display rule, the window display is performed according to the window information received from the second graphic synthesizer and the window information sent by the window management module in the first subsystem.

The window display rule includes one or any combination of the following rules:

Window focus setting rules;

Window position setting rules;

Window Z ordering rules.

The first graphics synthesizer is specifically configured to:

Execution when window display is performed according to the window position setting rule: according to the window information, the window type and/or the window layout are acquired, and the window display is performed according to the window type and/or the window layout and the window position setting rule.

The window Z-ordering rule includes the following rules: a Z-ordering order corresponding to each window type.

Window type information;

Window status information;

Window layout information;

The window displays the attribute information.

Preferably, the first subsystem is a Host subsystem, and the second subsystem is a Guest system.

Another window display method provided by the embodiment of the present application includes:

The first graphics synthesizer receives window information sent by the second graphics synthesizer; wherein the first graphics synthesizer is a graphics synthesizer in the first subsystem, and the second graphics synthesizer is in the second subsystem Graphic synthesizer

The first graphics synthesizer performs window display according to window information received from the second graphics synthesizer and window information sent by the window management module in the first subsystem.

Preferably, before the first graphics synthesizer receives the window information sent by the second graphics synthesizer, the method further includes:

The second graphics synthesizer receives the window information sent by the window management module of the second subsystem;

The second graphics synthesizer transmits the window information to the first graphics synthesizer.

The window display rule includes one or any combination of the following rules:

Window focus setting rules;

Window position setting rules;

Window Z ordering rules.

Among them, when the window is displayed according to the window position setting rule, it includes:

Window type information;

Window status information;

Window layout information;

The window displays the attribute information.

In the above embodiment of the present application, the window management module of the second subsystem sends the window information to the graphics synthesizer (second graphics synthesizer) in the subsystem, and the second graphics synthesizer sends the window information to the first sub- A graphics synthesizer (first graphics synthesizer) in the system, the first graphics synthesizer performs window display based on the window information received from the second graphics synthesizer and the window information sent by the window management module in the first subsystem. It can be seen that in the first subsystem and the second subsystem within an operating system framework, the processing operation of the window display is performed by the graphics synthesizer in the first subsystem, and the first graphics synthesizer can The window of the system and the window of the second subsystem are displayed, and the fusion is performed at the window level based on different operating systems.

The embodiment of the present application provides an information interaction method and system for implementing control and management of an application or service across operating systems.

The information interaction method provided by the embodiment of the present application includes:

The second connection service module in the second subsystem receives the control information sent by the application management module in the second subsystem;

The second connection service module sends the control information to a first connection service module in the first subsystem;

The first connection service module sends the control information to an application management module in the first subsystem.

Preferably, the method further comprises:

The first connection service module receives response information returned by the application management module in the first subsystem according to the control information;

The first connection service module sends the response information to the second connection service module;

The second connection service module sends the response information to an application management module in the second subsystem.

Preferably, the application management module comprises one or more of the following modules:

a component management module for managing application components or service components;

a window management module for managing an application window;

The installation package management module is used to manage the application installation package.

Preferably, the application management module in the second subsystem that sends the control information includes: an activity management module; the application management module in the first subsystem that receives the control information includes: a dynamic service component management service DPMS; or

The application management module in the second subsystem that sends the control information includes: a window management module; and the application management module in the first subsystem that receives the control information includes: a window management module; or

The application management module in the second subsystem that sends the control information includes: an installation package management module; and an application management module in the first subsystem that receives the control information includes: a static service component management module.

Preferably, the application management module in the second subsystem that sends the control information includes: a DPMS; the application management module in the first subsystem that receives the control information includes: an activity management module; or

The application management module in the second subsystem that sends the control information includes: a window management module; and the application management module in the first subsystem that receives the control information includes: a window management module Block; or,

The application management module in the second subsystem that sends the control information includes: a static service component management module; and an application management module in the first subsystem that receives the control information includes: an installation package management module.

Preferably, after receiving the subsystem switching related event, the application management module in the second subsystem sends control information to the second connection service module according to the received event.

Preferably, the first subsystem is a Host subsystem, and the second subsystem is a Guest subsystem; or

The second subsystem is a Host subsystem, and the first subsystem is a Guest subsystem.

An information interaction system provided by the embodiment of the present application includes: a first connection service module and an application management module in the first subsystem, a second connection module and an application management module in the second subsystem;

a second connection service module in the second subsystem, configured to receive control information sent by an application management module in the second subsystem; and send the control information to the first connection service in the first subsystem Module

The first connection service module is configured to send the control information to an application management module in the first subsystem.

Preferably, the first connection service module is further configured to:

Receiving, by the application management module in the first subsystem, the response information, according to the response information returned by the control information, to the second connection service module;

The second connection service module is further configured to:

Sending the response information to an application management module in the second subsystem.

a window management module for managing an application window;

Preferably, the application management module in the second subsystem is specifically configured to:

After receiving the subsystem switching related event, sending control information to the second connection service module according to the received event.

Another information interaction method provided by the embodiment of the present application includes:

The first connection service module in the first subsystem receives the control information sent by the second connection service module in the second subsystem;

Preferably, before the first connection service module in the first subsystem receives the control information sent by the second connection service module in the second subsystem, the method further includes:

The second connection service module sends the control information to a first connection service module in the first subsystem.

Preferably, the method further comprises:

The first connection service module sends the response information to the second connection service module, so that the second connection service module sends the response information to an application management module in the second subsystem.

a window management module for managing an application window;

The application management module in the second subsystem that sends the control information includes: a window management module The application management module in the first subsystem that receives the control information includes: a window management module; or

Another method of information interaction provided by the example of the present application includes:

The first connection service module in the first subsystem receives the control information sent by the first connection service module in the first subsystem;

The first connection service module sends the control information to a second connection service module in the second subsystem.

Preferably, after the first connection service module sends the control information to the second connection service module in the second subsystem, the method further includes:

The second connection service module in the second subsystem sends the control information received from the first connection service module to the application management module in the second subsystem.

Preferably, the method further comprises:

The first connection service module receives response information sent by the second connection service module in the second subsystem, where the response information is obtained by the application management module in the second subsystem according to the received control information;

The first connection service module sends the response information to an application management module in the first subsystem.

a window management module for managing an application window;

Preferably, the application management module in the first subsystem that sends the control information includes: a DPMS; the application management module in the second subsystem that receives the control information includes: an activity management module; or

The application management module in the first subsystem that sends the control information includes: a window management module; and the application management module in the second subsystem that receives the control information includes: a window management module; or

The application management module in the first subsystem that sends the control information includes: a static service component management module; and the application management module in the second subsystem that receives the control information includes: an installation package management module.

In the foregoing embodiment of the present application, the application management module in the second subsystem sends the control information to the first connection service module of the first subsystem by using the second connection service module in the second subsystem, by the first The connection service module sends the control information to the application management module in the first subsystem, and implements control information interaction across the operating system. Especially when the above embodiments are applied to inter-application switching of different subsystems, application management across operating systems can be realized.

DRAWINGS

1 is a schematic diagram of an operating system framework applicable to an embodiment of the present application;

2a and 2b are schematic diagrams of switching between Page in the Host subsystem and Actibity in the Guest subsystem, respectively;

3 is a schematic structural diagram of interaction of control information between a Host subsystem and a Guest subsystem according to an embodiment of the present application;

4 is a schematic structural diagram of a hybrid display of a Host subsystem and a Guest subsystem at a window level according to an embodiment of the present application;

FIG. 5 is a schematic diagram of window fusion display in an application scenario according to an embodiment of the present application;

FIG. 6 is a schematic structural diagram of a window display system according to an embodiment of the present application;

FIG. 7 is a schematic structural diagram of a control information interaction system according to an embodiment of the present application.

detailed description

In order to provide a seamless dual-system user experience for the user to provide a seamless dual-system user experience, the solution is provided in the embodiment of the present application. .

The different operating systems include a first operating system and a second operating system. Specifically, the first operating system may be a cloud operating system, and the second operating system may be a traditional operating system. More specifically, the first operating system may be YunOS and the second operating system may be Android.

The embodiments of the present application are described in detail below with reference to the accompanying drawings.

FIG. 1 is a schematic diagram of an operating system framework applicable to an embodiment of the present application. Taking YunOS as the first operating system and Android as the second operating system as an example, FIG. 1 shows a dual system compatible architecture within the YunOS framework.

As shown in Figure 1, the system framework includes two subsystems: Host and Guest. Among them, YunOS is the Host subsystem, Android is the Guest subsystem, and the two subsystems are isolated by the container technology. The Hardware Abstraction Layer (HAL) within the framework provides interfaces and driver services for graphical display and other aspects.

Glibc in the Host subsystem, the C runtime library, is the lowest API (Application Programming Interface) in Linux. Bioric in the Guest subsystem is the Linux kernel library for Android.

Libhybris is a compatibility layer that enables Glibc-based operating systems to reuse existing Android driver services; in graphics processing, libhybris also implements the EGL platform. EGL platform This is a backend-independent graphical platform that follows the EGL interface and multiple backend implementations.

The Gralloc module is located in the hardware abstraction layer and encapsulates all access operations to the framebuffer.

The InputManagerService (input management service) in the Guest subsystem is mainly used to monitor and manage input events.

SurfaceFlinger is the graphics synthesizer of the Guest subsystem; Wayland Compositor (or Weston) is the graphics synthesizer of the Host subsystem, where Weston is the reference implementation of the Wayland Compositor.

In the embodiment of the present application, the Wayland protocol can be used for communication between the graphics synthesizer of the Guest subsystem and the graphics synthesizer of the Host subsystem. The Wayland protocol defines how to communicate with the kernel and how to communicate with the client; Wayland reuses the graphics, input and output technologies of all Linux kernels.

In the above architecture, the Wayland protocol can be communicated between the graphic synthesizer of Andriod and the graphic synthesizer of YunOS in the embodiment of the present application, so that the graphics system in Android is overhead and bridged to the graphic system of YunOS, realizing the dual system. Uniform synthetic rendering provides better dual system compatibility and a seamless user experience with dual systems.

It should be noted that the above system architecture is only illustrated by YunOS and Andriod. For other types of operating systems, the compatibility and effective integration of dual systems at the window level and the control level can also be realized based on the above principles.

Based on the above framework, the embodiments of the present application provide dual system compatibility on the following two levels:

(1) Dual-system compatibility scheme at the control level

(2) Dual system compatibility scheme at the window level

In the actual application scenario, the above two dual system compatibility schemes may be used independently or in combination.

The following takes the first subsystem as the Host subsystem and the second subsystem as the Guest subsystem as an example to describe the two dual system compatibility schemes. Among them, the Host subsystem is YunOS, and the Guest subsystem is Android.

(1) Dual-system compatibility scheme at the control level

1. Host subsystem (YunOS) framework description

Within the framework of the Host subsystem (YunOS), Page is called a service component, which is an abstraction of local services and remote services, that is, the basic unit of services. By encapsulating data and methods, various services can be provided. A service scene can include multiple Pages. For example, a Page can be a UI (user interface), a photo or other service, or a background service, such as account authentication.

The running state Page is called the Page instance. It is the running carrier of the local service or the remote service. It can be created, scheduled, and managed by the DPMS (Dynamic Page Manager Service). The DPMS can maintain the life cycle of the Page instance. Each Page can be identified in YuOS using a URI (Uniform Resource Identifier).

PageLink is an information entity that flows between Pages and can pass information between Pages.

Within the framework of the Host Subsystem (YunOS), the following system services are mainly provided:

DPMS: DPMS can be seen as a service component management entity. DPMS can manage Page life cycle and runtime scheduling, Page lifecycle management from creation to destruction, and PageLink interaction between Pages can be achieved through DPMS;

Weston: Weston mainly includes window management, compositor and input management. From the general flow point of view, the input management module accepts user input, and then the shell makes corresponding window management operations (such as window stack changes, focus changes, etc.), and on the other hand, the input event (input event) ) Passed to the client (client) that previously registered the corresponding input event. After the client receives it, it will do the corresponding actions in the handler, such as adjusting the view and then redrawing. If redrawing occurs, the new graphics buffer (buffer) is completed, the client passes the handle of the buffer to the server, and then the server generates a list of windows in the z-order order. Then the compositor uses the renderer. (renderer) performs composition and finally outputs (such as output to framebuffer).

StaticPageService: Mainly responsible for managing the system's installation package (Package), including Package Installation, uninstallation, and information inquiry.

In the embodiment of the present application, the above-mentioned DPMS, Weston, and StaticPageService and other modules that can be used to implement application-related management functions are collectively referred to as an application management module.

2, Guest subsystem (Android) framework description

In the Guest subsystem (Android) framework, Activity is a component of the application, is the main body of the implementation of the application, it undertakes a lot of display and interaction work, an application usually contains multiple activities. An Activity can provide a separate visual UI (User Interface). Users can complete tasks such as dialing, taking photos, sending emails, searching, etc. through the UI provided by the Activity.

The management of the Activity uses a stacking mechanism, which follows the principle of advanced and outgoing, and the system always displays the Activity at the top of the ActivityStack stack.

Task refers to the combination of related activities, managed by ActivityStack. A Task can be composed of one or more applications. For example, if you need to take a photo and send it as a multimedia message when sending a text message, the user can first stop at the Acitivity of the SMS application and then jump to the Activity of the Camera application. When the camera function is completed, Then return to the Activity of the SMS application.

Within the framework of the Guest subsystem (Android), the following system services are mainly provided:

ActivityManagerService (Active Management Service): It is mainly responsible for managing application components, which may include components that manage the life cycle of the application process and components of the application process, such as Activity, Service, Broadcast, and Provider;

WindowManagerService (window management service): mainly responsible for window management in the system, such as management of window stack, focus (focus) management, etc.;

PackageManagerService (installation package management service): mainly responsible for the management of the system APK (AndroidPackage, Android installation package), such as the installation, uninstallation, deletion and other management of the APK. More specifically, it refers to the management of components, such as Activie, Service (service) Etc., etc., parsing the components from the APK and saving them to the relevant structure.

In the embodiment of the present application, the above-mentioned ActivityManagerService, WindowManagerService, and PackageManagerService, and other modules that can be used to implement application-related management functions are collectively referred to as an application management module.

It can be seen that the DPMS in YunOS and the ActivityManagerService in Android are functionally equivalent, both for managing application components or service components; the window management module in Weston in YunOS and the WindowManagerService in Android are functionally Peer-to-peer is used for window management; the StaticPageService in YunOS and the PackageManagerService in Android are functionally equivalent, and are used for application installation package management.

2a and 2b show schematic diagrams of switching between Page in the Host subsystem and Actibity in the Guest subsystem, respectively.

As shown in Figure 2a, the Page (Host Page) in the Host subsystem enters the Running state from the Start state, and the corresponding window of the Host Page is displayed; the Host Page can start the Activity in the Guest subsystem ( Guest Activity); The Guest Activity that is started can return the Host Page. The Guest Activity can also be called by the launched Guest Activity. The Host Page can also launch other Host Pages or return to the previous Host Page. Similarly, the Guest Activity can also launch other Guest Activity or return to the previous Guest Activity.

The switching between the Host Page and the Guest Activity shown in Figure 2b is similar to that shown in Figure 2a, except that the switching process is closed-loop, not an infinite loop. For example, the Host Page is not allowed to start other Host Pages; the Host Page starts the Guest Activity. After that, the Guest Activity is not allowed to return the Host Page.

Based on the architecture of the above two subsystems, in order to realize the interaction between different subsystems at the control level, in the embodiment of the present application, the Yunas Bridge Service is used to exchange control information between two subsystems, and the YunOS Bridge Service is a system service. Can be system resident Service, used to implement interactive control information between two subsystems. The YunOS Bridge Service establishes processes in the Host subsystem and the Guest subsystem respectively (for the purpose of distinguishing, the process established in the Host subsystem can be referred to as the first connection service module, and the process established in the Guest subsystem is called the first process. The second connection service module, and vice versa, the YunOS Bridge Service can use the Binder mechanism for information interaction between processes in the two subsystems.

Based on the architecture, after receiving the control information sent by the application management module in the guest subsystem, the second connection service module in the guest subsystem may send the control information to the first connection service module in the Host subsystem. A connection service module can send the control information to an application management module in the Host subsystem for processing.

The control information includes control information related to switching between subsystems. For example, the switching operation between subsystems may include: switching between application components in different subsystems, and switching between application windows in different subsystems. Calls or switches between application installation packages in different subsystems.

In some embodiments, the application management module in the Guest subsystem may send control information to the second connection service module in the Guest subsystem according to the received event after receiving the inter-subsystem handover related event.

In combination with the system service provided by the Host subsystem and the system service provided by the Guest subsystem, as shown in FIG. 3, the foregoing control information interaction process may include the following situations:

Situation 1:

The ActivityManagerService in the Guest subsystem sends control information to the YunOS Bridge Service (the second connection service module in the figure) in the Guest subsystem. The YunOS Bridge Service in the Guest subsystem sends the control information to the YunOS in the Host subsystem. The Bridge Service (the first connection service module in the figure), the YunOS Bridge Service in the Host subsystem sends the control information to the DPMS in the Host subsystem.

In some embodiments, the ActivityManagerService can be received to indicate from After the activity is switched to the event of the Page in the Host subsystem, the control information is sent to the YunOS Bridge Service in the Guest subsystem, and the control information may be the event or the control information related to the application component switch generated according to the event. . Further, after receiving the event, the ActivityManagerService also manages the corresponding Activity of the subsystem according to the event.

For example, an event that indicates a switch from an Activity to a Page in the Host subsystem can include one of the following events:

- The Activity in the Guest subsystem starts the Page in the Host subsystem;

The Activity in the -Guest subsystem returns to the previous Page in the Host subsystem.

Further, after receiving the control information from the guest subsystem, the DPMS in the Host subsystem performs corresponding processing according to the control information. For example, for the operation of starting the Page, the life cycle of the Page is managed; for example, for the operation of returning the Page, the status of the Page is updated.

Further, the DPMS in the Host subsystem may also send the processing result for the control information as a response message to the YunOS Bridge Service in the Host subsystem, and the YunOS Bridge Service in the Host subsystem sends the response information to the Guest subsystem. ActivityManagerService.

Further, if the Activity in the Guest subsystem starts other activities in the subsystem or returns to other activities in the subsystem, the ActivityManagerService in the Guest subsystem manages the switching operations of the Activity, including, for example, the management of the Activity. ActivityStack management, task management, etc.

Case 2:

The control information sent by the DPMS in the Host subsystem to the YunOS Bridge Service in the Guest subsystem, the YunOS Bridge Service in the Host subsystem sends the control information to the YunOS Bridge Service in the Guest subsystem, and the YunOS Bridge in the Guest subsystem. The Service sends the control information to the ActivityManagerService in the Guest subsystem.

In some embodiments, the DPMS may send control information to the YunOS Bridge Service in the Host subsystem after receiving an event indicating that the activity is switched from the Page to the Guest subsystem, and the control information may specifically be the event. It may also be control information related to application component switching generated according to the event. Further, after receiving the event, the DPMS also manages the corresponding page of the subsystem according to the event.

For example, an event that indicates switching from Page to an Activity in the Guest subsystem can include one of the following events:

- The Page in the Host subsystem starts the Activity in the Guest subsystem;

The Page in the -Host subsystem returns to the previous Activity in the Guest subsystem.

Further, after receiving the control information from the Host subsystem, the ActivityManagerService in the Guest subsystem performs corresponding processing according to the control information. For example, for the operation of starting the Activity, the Activity is placed in the ActivityStack; for example, for the operation of returning the Activity, the Activity is taken out from the ActivityStack.

Further, the ActivityManagerService in the Guest subsystem may also send the processing result for the control information as a response message to the YunOS Bridge Service in the Guest subsystem, and the YunOS Bridge Service in the Host subsystem sends the response information to the Host subsystem. In the DPMS.

Further, if the Page in the Host subsystem starts other pages in the subsystem or returns to other pages in the subsystem, the DPMS in the Host subsystem manages the switching operation of the Page.

Case 3:

The control information sent by the WindowManagerService in the Guest subsystem to the YunOS Bridge Service in the Guest subsystem, and the YunOS Bridge Service in the Guest subsystem sends the control information to the YunOS Bridge Service in the Host subsystem, the Host subsystem. The YunOS Bridge Service in the control sends the control information to Weston in the Host subsystem, and more specifically to the window management module in Weston.

In some embodiments, the WindowManagerService may send control information to the YunOS Bridge Service in the Guest subsystem upon receiving an event indicating that the Activity window (or UI) is switched to the Page window (or UI) in the Host subsystem. The control information may specifically be the event, or may be control information related to window switching generated according to the event. Further, after the WindowManagerService receives the event, the corresponding application window of the subsystem is also managed according to the event.

For example, an event that indicates switching from the Activity UI to the Page UI can include one of the following events:

- The Activity in the Guest subsystem starts the Page in the Host subsystem, and the UI of the Page is created;

The Activity in the -Guest subsystem returns to the previous Page in the Host subsystem, and the UI of the Page is redrawn.

Further, after receiving the control information from the Guest subsystem, the window management module in the Weston of the Host subsystem performs corresponding processing according to the control information. For example, for the operation of starting the Page, the UI of the Page is created; for example, for the operation of returning the Page, the UI of the Page is redrawed.

Further, if the Activity in the Guest subsystem starts other activities in the subsystem or returns to other activities in the subsystem, the window switch caused by the Activity switching operation is performed by the WindowManagerService in the Guest subsystem. Management, such as updating window status, setting focus, and more.

Situation 4:

The control information sent by the window management module in Weston of the Host subsystem to the YunOS Bridge Service in the Guest subsystem, and the YunOS Bridge Service in the Host subsystem sends the control information to the YunOS Bridge Service in the Guest subsystem, the Guest subsystem. The YunOS Bridge Service in the middle sends the control information to the WindowManagerService in the Guest subsystem.

In some embodiments, the window management module in Weston may, after receiving an event indicating that the activity (or UI) in the Guest subsystem is switched from the Page window (or UI), to the YunOS Bridge in the Host subsystem. The service sends control information, which may be the event, or may be control information related to window switching generated according to the event. Further, after receiving the event, the window management module in Weston also manages the corresponding application window of the subsystem according to the event.

For example, an event that indicates switching from the Page UI to the Activity UI can include one of the following events:

- The Page in the Host subsystem starts the Activity in the Guest subsystem, and the UI of the Activity is created;

The Page in the -Host subsystem returns to the previous Activity in the Guest subsystem, and the UI of the Activity is redrawn.

Further, after receiving the control information from the Host subsystem, the WindowManagerService in the Guest subsystem performs corresponding processing according to the control information. For example, for the operation of starting the Activity, create the UI of the Activity; for example, for the operation of returning the Activity, redraw the UI of the Activity.

Further, the WindowManagerService in the Guest subsystem may also send the processing result for the control information as a response message to the YunOS Bridge in the Guest subsystem. Service, the YunOS Bridge Service in the Host subsystem sends the response information to the window management module in Weston in the Host subsystem.

Further, if the Page in the Host subsystem starts other pages in the subsystem or returns to other pages in the subsystem, the window management module in the Weston of the Host subsystem performs the window switching caused by the Page switching operation. Management, such as updating window status, setting focus, and more.

Case 5:

The control information sent by the PackageManagerService in the Guest subsystem to the YunOS Bridge Service in the Guest subsystem, the YunOS Bridge Service in the Guest subsystem sends the control information to the YunOS Bridge Service in the Host subsystem, and the YunOS Bridge in the Host subsystem. The Service sends the control information to the StaticPageService in the Host subsystem.

In some embodiments, the PackageManagerService may send control information to the YunOS Bridge Service in the Guest subsystem after receiving an event indicating that the application installation package in the Host subsystem is invoked, the control information may specifically be the event. It can also be related to the control information generated by the application installation package generated by the event.

Further, after receiving the control information from the Guest subsystem, the StaticPageService in the Host subsystem performs corresponding processing according to the control information.

Further, the StaticPageService in the Host subsystem may also send the processing result for the control information as a response message to the YunOS Bridge Service in the Host subsystem, and the YunOS Bridge Service in the Host subsystem sends the response information to the Guest subsystem. The PackageManagerService in .

Further, if the application installation package in the Guest subsystem is invoked, it is managed by the PackageManagerService in the Guest subsystem.

Case 6:

The control information sent by the StaticPageService in the Host subsystem to the YunOS Bridge Service in the Host subsystem, the YunOS Bridge Service in the Host subsystem sends the control information to the YunOS Bridge Service in the Guest subsystem, and the YunOS Bridge in the Guest subsystem. The Service sends the control information to the PackageManagerService in the Guest subsystem.

In some embodiments, the StaticPageService may send control information to the YunOS Bridge Service in the Host subsystem after receiving an event indicating that the application installation package in the Guest subsystem is invoked, the control information may specifically be the event. It can also be related to the control information generated by the application installation package generated by the event.

Further, after receiving the control information from the Host subsystem, the PackageManagerService in the Guest subsystem performs corresponding processing according to the control information.

Further, the PackageManagerService in the Guest subsystem may also send the processing result for the control information as a response message to the YunOS Bridge Service in the Guest subsystem, and the YunOS Bridge Service in the Guest subsystem sends the response information to the Host subsystem. In the StaticPageService.

Further, if the application installation package in the Host subsystem is called, it is managed by the StaticPageService in the Host subsystem.

In actual application scenarios, when inter-subsystem switching occurs, the above various situations may occur simultaneously, or only one of them may occur. For example, when switching from Activity to Page, Case 1 and Case 3 above may occur at the same time.

As can be seen from the above description, within the above-mentioned YunOS system framework, the YunOS (Host Subsystem) application and the Android (Guest Subsystem) application can operate independently based on their respective subsystems, but in the case of switching between applications, The above method notifies the subsystem in which the handover target is located for management, so that the applications of the two systems have mutual integration and mutual return on the life cycle, and the user experience has a consistent application startup and return mode, thereby Android applications are integrated into the YunOS application.

(2) Dual system compatibility scheme at the window level

In the embodiment of the present application, the WindowManagerService in the Guest subsystem may send the window information to the SurfaceFlinger, and the SurfaceFlinger sends the window information to the Weston in the Host subsystem, and the Weston may according to the window information received from the SurfaceFlinger and the window information in the Weston. The window is displayed.

The window involved in the foregoing process may include an application window and/or an operating system window, or other types of windows, which are not limited in this embodiment of the present application.

Preferably, Weston can display the window according to the window display rule, based on the window information received from SurfaceFlinger and the window information in Weston.

Wherein, the window information may include one or any combination of the following:

- window type information

Window types can be divided from a variety of perspectives, such as system-level windows (such as the UI provided by the operating system) and application-level windows (such as the UI provided by the application); for example, floating UI and non-floating UI; for example, Interactive class windows (such as the ability to provide interaction with the user, receive and respond to user actions) and non-interactive class windows, and so on.

- window status information

Window states can include visible, non-visible, and the like.

- window layout information

The window layout can include full screen display or half screen display.

- window display attribute information

The window display attribute information may include one or more of a plurality of attribute parameters such as display color, transparency, and the like.

The above solution can be applied to scenarios in which applications of different subsystems are simultaneously opened under the YunOS architecture. Through the above method, it can be different by the graphics synthesizer (Weston) of the Host subsystem. The subsystem's windows are managed in a unified manner, so that the windows of different subsystems can be displayed reasonably.

In some embodiments, in order to properly layout and manage windows of different subsystems, window display rules may be preset in a graphics synthesizer of the Host subsystem. For example, the window display rules may include one or more of the following rules. Kind:

- window focus setting rules

Weston can determine the window in focus and set the window focus according to the window focus setting rules. Preferably, the following rules may be included in the window focus setting rule: the focus setting priority corresponding to the various window types. For example, the priority of the application-level window can be higher than the priority of the system-level window, which is convenient for the user to use the application; for example, in the system-level window, the priority of the system main interface can be higher than other system-level windows.

Preferably, the focus corresponding to the remote interaction class window is set to a priority, which may be higher than the focus setting corresponding to other types of windows. For example, for a window that can receive the remote control signal, the priority of obtaining the focus is higher than the priority. A window that receives the remote control signal (such as a status bar window), which is more in line with the user's operating habits (the possibility of using the remote control to control the operation is usually greater than the possibility of operating the status bar), which is convenient for the user to operate.

For the current scenes that need to be displayed, in the specific implementation, Weston can obtain the window types of the N windows according to the N window information, and determine the N according to the window focus setting rules and the window types of the N windows. The window in which the focus is in the window.

- Window position setting rules

Weston can determine where the window is located based on the window location setting rules. In particular, the location of the window can be related to the window type and/or window layout. For example, if the status bar window and the video window are currently open, the status bar window can be set to the upper edge position of the video window.

Correspondingly, when the window is displayed according to the window position setting rule, the window type and/or the window layout can be obtained according to the window information, according to the window type and/or the window layout and the window position. Set the rules to determine the window position and display the window.

- window z-order (z-order) arrangement rules

Weston can determine the z-order of the window based on the window z-order setting rules. Preferably, the window Z-ordering rule may include the following rules: a Z-ordering order corresponding to the various window types. Preferably, the floating UI is usually at the top.

For the scene where there are currently N windows to be displayed, in the specific implementation, when the window is displayed according to the window Z-ordering rules, Weston can obtain the window types of the N windows according to the window information of the N windows, and according to the window The Z-ordering rules and the window types of the N windows determine the Z-ordering order of the N windows.

Figure 4 shows a schematic diagram of the architecture of two subsystems mixed at the window level. As shown in the figure, the WindowManagerService in the Guest subsystem sends the window information of the window object it manages, such as the window state (WindowState) or surface (surface), to the SurfaceFlinger in the Guest subsystem through the ComposerService as the client, which is more specific. The ground is sent to the layer in SurfaceFlinger. SurfaceFlinger sends the window information to Weston of the Host subsystem, which can be interacted through the Waland protocol. On the one hand, Weston receives the window information sent by SurfaceFlinger, and on the other hand receives the window information of the subsystem (such as the window information transmitted by PageWindow in the figure). Weston can manage the windows of the two subsystems according to the window display rules.

It can be seen that the window management module in the Host subsystem controls and displays the window display of the Host subsystem, and the window display of the Guest subsystem, coordinates and manages the creation, destruction, screen layout, and window z- of each of the two systems. Order, focus settings, etc.

As an example, there are 2 applications in the Guest subsystem, which open window A and window B respectively; one application in the Host subsystem is opened, and the corresponding window is window C. In this case, the WindowManagerService in the Guest subsystem manages the following information: Window A and Window B types (system level, application level), window status, window layout (full screen / half screen), etc. Information, through the above mechanism, these window information is sent to the window management module WindowManager in Yunon's Weston; YunOS's WindowManager determines the display mode of window A, window B and window C based on the window display rules (including window position, Z-order, focus) The window, etc.), which is displayed by the YunOS graphics synthesizer. From the user's point of view, the user can't perceive which windows on the screen are the Android system of the YunOS system at the moment, so that the visual and control effects are consistent and enhance the user experience.

FIG. 5 exemplarily shows an example of displaying a window of a plurality of applications on a screen based on a dual-system compatibility scheme of a window level provided by an embodiment of the present application.

As shown in FIG. 5, windows of a plurality of applications may be displayed on the screen of the device 100. In this example, the application windows may include:

The Status Status Bar 501 is a system level window in the Host subsystem for displaying system status information.

The Volume Control window (Android Volume Control) 502 is a system level window in the Guest subsystem for adjusting the volume;

The floating UI (Android Floating UI) 503 is an application-level window in the Guest subsystem, and is used to implement system performance optimization services when triggered.

A remotely controlled playback UI (Host Player UI with remote) 504 is an application-level window in the Host subsystem, and can receive a control signal sent by the remote controller 200 and respond to implement a video playback control function.

The Host Video Surface 505 is an application-level window in the Host subsystem for displaying video.

In a scenario, on the device 100, a status bar (501), a volume control window (502), and a remotely controllable UI (Host Player UI with remote) 504 are currently displayed. , Video Video Surface 505, Host Video Surface 505 is playing a video.

At this time, the user triggers the volume control window 502 to adjust the volume and attempts to fast forward the video content. At this time, the background resource overhead is large, so the floating UI (Android Floating UI) 503 is displayed on the screen for the user to select for system performance optimization. At this time, the window of the application 100 is displayed on the desktop of the device 100, and some of the windows are windows in the Host subsystem, and some of the windows are windows in the Guest subsystem. The Z-order and layout of the windows can be Host. The graphics synthesizer in the system is determined based on the set window display rules. In this example, the Z-order order and window layout of each of the above windows can be seen in FIG.

From the user's point of view, it is impossible to perceive which windows on the desktop are the windows of the Host subsystem, and which windows are the windows of the Guest subsystem, thereby providing a consistent fusion effect visually and manipulated to enhance the user experience.

Based on the same technical concept, the embodiment of the present application provides a window display system, which can implement the window display method provided by the foregoing embodiment.

FIG. 6 is a schematic structural diagram of a window display system according to an embodiment of the present disclosure, where the system may include:

a second graphics synthesizer 62, configured to receive window information sent by the window management module 61 of the second subsystem, and send the window information to the first graphics synthesizer; the first graphics synthesizer 63 is in the first subsystem a graphics synthesizer, the second graphics synthesizer 62 is a graphics synthesizer in the second subsystem;

The first graphics synthesizer 63 is configured to perform window display according to the window information received from the second graphics synthesizer 62 and the window information sent by the window management module (not shown in the figure) in the first subsystem.

Preferably, the first graphics synthesizer 63 is specifically configured to: according to the window display rule, perform window display according to the window information received from the second graphics synthesizer and the window information sent by the window management module in the first subsystem.

The window display rule includes one or any combination of the following rules:

Window focus setting rules;

Window position setting rules;

Window Z ordering rules.

The first graphics synthesizer 63 is specifically configured to: perform window display according to the window position setting rule: obtain a window type and/or a window layout according to the window information, and set a rule according to the window type and/or the window layout and the window position. The window is displayed.

Window type information;

Window status information;

Window layout information;

The window displays the attribute information.

Based on the same technical concept, the embodiment of the present application provides an information interaction system, which can implement the information interaction process provided by the foregoing embodiment.

FIG. 7 is a schematic structural diagram of an information interaction system according to an embodiment of the present application. The system may include: a first connection service module 71 and an application management module 73 in the first subsystem, and a second connection in the second subsystem. Module 72 and application management module 74, wherein:

The second connection service module 72 is configured to receive the control information sent by the application management module 74 in the second subsystem; and send the control information to the first connection service module 71 in the first subsystem;

The first connection service module 71 is configured to send the control information to the application management module 73 in the first subsystem.

Preferably, the first connection service module 71 is further configured to: receive the response information returned by the application management module 73 in the first subsystem according to the control information, and send the response information to the second connection service module 72;

The second connection service module 72 is further configured to: send the response information to the application management module 74 in the second subsystem.

a window management module for managing an application window;

Preferably, the application management module 74 in the second subsystem is specifically configured to: after receiving the subsystem switching related event, send control information to the second connection service module according to the received event.

Preferably, the first subsystem is a Host subsystem, and the second subsystem is a Guest subsystem; or the second subsystem is a Host subsystem, and the first subsystem is a Guest subsystem.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (system), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine for the execution of instructions for execution by a processor of a computer or other programmable data processing device. Means for implementing the functions specified in one or more of the flow or in a block or blocks of the flow chart.

The computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device. The apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.

These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device. Instructions are provided for implementation The steps of a function specified in a block or blocks of a flow or a flow and/or a block diagram of a flow chart.

While the preferred embodiment of the present application has been described, it will be apparent that those skilled in the art can make further changes and modifications to the embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and the modifications and

It will be apparent to those skilled in the art that various modifications and changes can be made in the present application without departing from the spirit and scope of the application. Thus, it is intended that the present invention cover the modifications and variations of the present invention.

Claims

A window display method, comprising:

The second graphics synthesizer receives window information sent by the window management module of the second subsystem, and the second graphics synthesizer is a graphics synthesizer in the second subsystem;

The second graphics synthesizer sends the window information to a first graphics synthesizer, the first graphics synthesizer being a graphics synthesizer in the first subsystem;

The first graphics synthesizer performs window display according to window information received from the second graphics synthesizer and window information sent by the window management module in the first subsystem.
The method according to claim 1, wherein said first graphics synthesizer according to a window display rule, based on window information received from said second graphics synthesizer and a window sent by a window management module in said first subsystem Information, window display.
The method of claim 2 wherein said window display rule comprises one or any combination of the following rules:

Window focus setting rules;

Window position setting rules;

Window Z ordering rules.
The method according to claim 3, wherein the window focus setting rule includes the following rules: a focus setting priority corresponding to each window type.
The method according to claim 3, wherein when the window is displayed according to the window position setting rule, the method comprises:

Obtaining a window type and/or a window layout according to the window information;

The window is displayed according to the window type and/or window layout and window position setting rules.
The method according to claim 3, wherein the window Z-ordering rule includes the following rules: a Z-ordering order corresponding to the various window types.
The method of claim 1 wherein said window information comprises one or any combination of the following:

Window type information;

Window status information;

Window layout information;

The window displays the attribute information.
The method according to any one of claims 1 to 7, wherein the first subsystem is a Host subsystem and the second subsystem is a Guest subsystem.
An information interaction method, comprising:

The second connection service module in the second subsystem receives the control information sent by the application management module in the second subsystem;

The second connection service module sends the control information to a first connection service module in the first subsystem;

The first connection service module sends the control information to an application management module in the first subsystem.
The method of claim 9 further comprising:

The first connection service module receives response information returned by the application management module in the first subsystem according to the control information;

The first connection service module sends the response information to the second connection service module;

The second connection service module sends the response information to an application management module in the second subsystem.
The method of claim 9 wherein said application management module comprises one or more of the following modules:

a component management module for managing application components or service components;

a window management module for managing an application window;

The installation package management module is used to manage the application installation package.
The method of claim 9 wherein:

The application management module in the second subsystem that sends the control information includes: an activity management module; and the application management module in the first subsystem that receives the control information includes: a dynamic service group Piece management service DPMS; or,

The application management module in the second subsystem that sends the control information includes: a window management module; and the application management module in the first subsystem that receives the control information includes: a window management module; or

The application management module in the second subsystem that sends the control information includes: an installation package management module; and an application management module in the first subsystem that receives the control information includes: a static service component management module.
The method of claim 9 wherein:

The application management module in the second subsystem that sends the control information includes: a DPMS; the application management module in the first subsystem that receives the control information includes: an activity management module; or

The application management module in the second subsystem that sends the control information includes: a window management module; and the application management module in the first subsystem that receives the control information includes: a window management module; or

The application management module in the second subsystem that sends the control information includes: a static service component management module; and an application management module in the first subsystem that receives the control information includes: an installation package management module.
The method of claim 9, wherein the application management module in the second subsystem sends the control information to the second connection service module according to the received event after receiving the subsystem switching related event.
The method according to any one of claims 9 to 14, wherein the first subsystem is a Host subsystem and the second subsystem is a Guest subsystem; or

The second subsystem is a Host subsystem, and the first subsystem is a Guest subsystem.
A window display system, comprising:

a second graphics synthesizer, configured to receive window information sent by a window management module of the second subsystem, where the second graphics synthesizer is a graphics synthesizer in the second subsystem, and send the window information to the first graphics a synthesizer, the first graphics synthesizer is a graphics combination in the first subsystem Generator

And a first graphics synthesizer configured to perform window display according to the window information received from the second graphics synthesizer and the window information sent by the window management module in the first subsystem.
The system according to claim 16, wherein said first graphics synthesizer is specifically configured to: according to a window display rule, according to window information received from the second graphics synthesizer and window management in the first subsystem The window information sent by the module is displayed in the window.
The system of claim 17 wherein said window display rule comprises one or any combination of the following rules:

Window focus setting rules;

Window position setting rules;

Window Z ordering rules.
The system according to claim 18, wherein said window focus setting rule includes the following rules: a focus setting priority corresponding to each window type.
The system according to claim 18, wherein the first graphics synthesizer is specifically configured to: perform window display according to a window position setting rule: acquiring a window type and/or a window layout according to the window information, according to The window type and/or window layout and window position setting rules are displayed in the window.
The system according to claim 18, wherein said window Z-ordering rule includes the following rules: a Z-ordering order corresponding to the various window types.
The system of claim 16 wherein said window information comprises one or any combination of the following:

Window type information;

Window status information;

Window layout information;

The window displays the attribute information.
The system of any of claims 16 to 21, wherein the first subsystem is a Host subsystem and the second subsystem is a Guest subsystem.
An information interaction system, comprising: a first connection service module and an application management module in the first subsystem, a second connection module and an application management module in the second subsystem;

a second connection service module in the second subsystem, configured to receive control information sent by an application management module in the second subsystem; and send the control information to the first connection service in the first subsystem Module

The first connection service module is configured to send the control information to an application management module in the first subsystem.
The system of claim 24, wherein the first connection service module is further configured to: receive, by the application management module in the first subsystem, the response information according to the control information, and send the response information Giving the second connection service module;

The second connection service module is further configured to: send the response information to an application management module in the second subsystem.
The system of claim 24 wherein said application management module comprises one or more of the following modules:

a component management module for managing application components or service components;

a window management module for managing an application window;

The installation package management module is used to manage the application installation package.
The system of claim 24 wherein:

The application management module in the second subsystem that sends the control information includes: an activity management module; the application management module in the first subsystem that receives the control information includes: a dynamic service component management service DPMS; or

The application management module in the second subsystem that sends the control information includes: a window management module; and the application management module in the first subsystem that receives the control information includes: a window management module; or

The application management module in the second subsystem that sends the control information includes: an installation package management module; and an application management module in the first subsystem that receives the control information includes: a static service Component management module.
The system of claim 24 wherein:

The application management module in the second subsystem that sends the control information includes: a DPMS; the application management module in the first subsystem that receives the control information includes: an activity management module; or

The application management module in the second subsystem that sends the control information includes: a window management module; and the application management module in the first subsystem that receives the control information includes: a window management module; or

The application management module in the second subsystem that sends the control information includes: a static service component management module; and an application management module in the first subsystem that receives the control information includes: an installation package management module.
The system according to claim 24, wherein the application management module in the second subsystem is specifically configured to: after receiving the subsystem switching related event, serve the second connection according to the received event The module sends control information.
The system according to any one of claims 24 to 29, wherein the first subsystem is a Host subsystem and the second subsystem is a Guest subsystem; or

The second subsystem is a Host subsystem, and the first subsystem is a Guest subsystem.
A window display method, comprising:

The first graphics synthesizer receives window information sent by the second graphics synthesizer; wherein the first graphics synthesizer is a graphics synthesizer in the first subsystem, and the second graphics synthesizer is in the second subsystem Graphic synthesizer

The first graphics synthesizer performs window display according to window information received from the second graphics synthesizer and window information sent by the window management module in the first subsystem.
The method of claim 31, wherein before the first graphics synthesizer receives the window information sent by the second graphics synthesizer, the method further includes:

The second graphics synthesizer receives the window information sent by the window management module of the second subsystem;

The second graphics synthesizer transmits the window information to the first graphics synthesizer.
The method according to claim 31, wherein said first graphics synthesizer according to window display rules, based on window information received from said second graphics synthesizer and a window sent by said window management module in said first subsystem Information, window display.
The method of claim 33, wherein the window display rule comprises one or any combination of the following rules:

Window focus setting rules;

Window position setting rules;

Window Z ordering rules.
The method according to claim 34, wherein the window focus setting rule includes the following rules: a focus setting priority corresponding to each window type.
The method according to claim 34, wherein when the window is displayed according to the window position setting rule, the method comprises:

Obtaining a window type and/or a window layout according to the window information;

The window is displayed according to the window type and/or window layout and window position setting rules.
The method according to claim 34, wherein the window Z-ordering rule includes the following rules: a Z-ordering order corresponding to the various window types.
The method of claim 31, wherein the window information comprises one or any combination of the following:

Window type information;

Window status information;

Window layout information;

The window displays the attribute information.
The method according to any one of claims 31 to 38, wherein the first subsystem is a Host subsystem and the second subsystem is a Guest subsystem.
An information interaction method, comprising:

The first connection service module in the first subsystem receives the control information sent by the second connection service module in the second subsystem;

The first connection service module sends the control information to an application management module in the first subsystem.
The method of claim 40, wherein before the first connection service module in the first subsystem receives the control information sent by the second connection service module in the second subsystem, the method further includes:

The second connection service module in the second subsystem receives the control information sent by the application management module in the second subsystem;

The second connection service module sends the control information to a first connection service module in the first subsystem.
The method of claim 40, further comprising:

The first connection service module receives response information returned by the application management module in the first subsystem according to the control information;

The first connection service module sends the response information to the second connection service module, so that the second connection service module sends the response information to an application management module in the second subsystem.
The method of claim 40, wherein the application management module comprises one or more of the following modules:

a component management module for managing application components or service components;

a window management module for managing an application window;

The installation package management module is used to manage the application installation package.
The method of claim 40 wherein:

The application management module in the second subsystem that sends the control information includes: an activity management module; the application management module in the first subsystem that receives the control information includes: a dynamic service component management service DPMS; or

The application management module in the second subsystem that sends the control information includes: a window management module; and the application management module in the first subsystem that receives the control information includes: a window management module; or

The application management module in the second subsystem that sends the control information includes: an installation package management module; and an application management module in the first subsystem that receives the control information includes: a static service component management module.
The method according to any one of claims 40 to 44, wherein the first subsystem is a Host subsystem and the second subsystem is a Guest subsystem.
An information interaction method, comprising:

The first connection service module in the first subsystem receives the control information sent by the first connection service module in the first subsystem;

The first connection service module sends the control information to a second connection service module in the second subsystem.
The method of claim 46, wherein after the first connection service module sends the control information to the second connection service module of the second subsystem, the method further includes:

The second connection service module in the second subsystem sends the control information received from the first connection service module to the application management module in the second subsystem.
The method of claim 47, further comprising:

The first connection service module receives response information sent by the second connection service module in the second subsystem, where the response information is obtained by the application management module in the second subsystem according to the received control information;

The first connection service module sends the response information to an application management module in the first subsystem.
The method of claim 46, wherein the application management module comprises one or more of the following modules:

a component management module for managing application components or service components;

a window management module for managing an application window;

The installation package management module is used to manage the application installation package.
The method of claim 46, wherein

The application management module in the first subsystem that sends the control information includes: DPMS; The application management module in the second subsystem that receives the control information includes: an activity management module; or

The application management module in the first subsystem that sends the control information includes: a window management module; and the application management module in the second subsystem that receives the control information includes: a window management module; or

The application management module in the first subsystem that sends the control information includes: a static service component management module; and the application management module in the second subsystem that receives the control information includes: an installation package management module.
The method according to any one of claims 46 to 50, wherein the first subsystem is a Host subsystem and the second subsystem is a Guest subsystem.