CN117992189A

CN117992189A - Window realization method under multiple systems and electronic equipment

Info

Publication number: CN117992189A
Application number: CN202211372439.8A
Authority: CN
Inventors: 卞超
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-11-03
Filing date: 2022-11-03
Publication date: 2024-05-07

Abstract

The application provides a window realization method under multiple systems and electronic equipment, relates to the technical field of electronic equipment, and can realize the window function of an operating system under the condition of coexistence of multiple systems. The method comprises the following steps: responding to a first user operation, and sending a first request to a gateway service by a first operating system, wherein the first request is used for realizing a target function; the second operating system receives the first request from the gateway service; responding to the first request, and realizing a target function through a target service in the second operating system; the first operating system and the second operating system are both installed in the electronic equipment, the first operating system runs in the semi-container, the second operating system runs outside the semi-container, and the first operating system does not comprise target services.

Description

Window realization method under multiple systems and electronic equipment

Technical Field

The embodiment of the application relates to the technical field of electronic equipment, in particular to a window realization method under multiple systems and the electronic equipment.

Background

As the variety of electronic devices increases, different device types need to be compatible with different operating systems, and multi-system coexistence has become a mainstream. However, in a running environment where multiple systems coexist, how to implement windows of an operating system is a problem to be solved.

Disclosure of Invention

The application provides a window realization method under multiple systems and electronic equipment, which can realize the window function of an operating system under the condition of coexistence of the multiple systems.

In order to achieve the above purpose, the application adopts the following technical scheme:

In a first aspect, the present application provides a method for implementing a window in multiple systems, applied to an electronic device, where the method includes: responding to a first user operation, and sending a first request to a gateway service by a first operating system, wherein the first request is used for realizing a target function; the second operating system receives the first request from the gateway service; responding to the first request, and realizing a target function through a target service in the second operating system; the first operating system and the second operating system are both installed in the electronic equipment, the first operating system runs in the semi-container, the second operating system runs outside the semi-container, and the first operating system does not comprise target services.

Based on the above technical scheme, when the electronic device is provided with the first operating system and the second operating system and receives the first user operation, the first operating system running in the semi-container can send a first request to realize the target function through the gateway service, and correspondingly, the second operating system outside the semi-container can receive the first request from the gateway service and respond to the first request to realize the target function through the target service in the second operating system, wherein the first operating system does not comprise the target service. That is, when a service is not included in the operating system within the semi-container, it can implement a desired function by calling a corresponding service in the operating system outside the semi-container. Such as: the target function may be a window function such that in case of multi-system coexistence, an operating system may be implemented, such as: including but not limited to the window functions of the operating system within the semi-container.

In one possible design, the first user operation includes a user operation on a first application running in a first operating system or the first application running in a second operating system. Based on the design, the first user operation may be an operation for a first application that runs in either the first or second operating system. I.e. the target function may be either an application-triggered function running inside the semi-container or an application-triggered function running outside the semi-container. That is, the operating system outside the half-container may call the service of the operating system inside the half-container, and may also switch back to the service calling the operating system outside the half-container when the corresponding service does not exist inside the half-container. The operating system within the semi-container may also invoke services of the operating system outside the semi-container. A call to a service of the operating system across the semi-containers is implemented.

In one possible design, the target function comprises a window function and the target service comprises a window management service WMS.

In one possible design, the window function includes one or more of the following: acquiring window attributes, adjusting window sizes, acquiring window focuses, managing window life cycles, and acquiring or setting window modes; the window attribute comprises one or more of window size, window name and window identification, and the management window life cycle comprises: one or more of creating a window, displaying a window, hiding a window, destroying a window.

In one possible design, the method further comprises: responding to a second user operation, loading a first library file by the first operating system, wherein the first library file corresponds to a second library file of the first operating system, the first library file is a library file corresponding to the second operating system, the first library file is compatible with the second operating system, and the second library file is incompatible with the second operating system. Based on the design, when the first operating system loads the library file, if the first operating system determines that the library file is incompatible with the second operating system, the library file corresponding to the library file and compatible with the second operating system can be loaded. In this way, the first operating system may avoid the problem of ABI incompatibility when invoking the system capabilities of the second operating system.

In one possible design, the first library file is pre-placed in the first operating system.

In one possible design, a first operating system loads a first library file, comprising: the first operating system relocates to the first library file through the linker during loading of the second library file.

In one possible design, the first library file includes libegl.so and libgles.so; the first operating system loads libegl.so and libgles.so, including: and loading libEGL.so through the EGL in the first operating system and loading libGLES.so through OpenGLES in the first operating system, so as to complete the rendering operation of the graph. Based on the design, when the graphics are rendered by adopting the EGL and OpenGLES by the operating system in the semi-container, library files respectively loaded by the EGL and OpenGLES are library files compatible with the operating system in the semi-container. Thus, the operating system in the semi-container can avoid the problem of incompatibility of ABI when the operating system outside the semi-container is called to execute the graphic composition and the display sending operation.

In one possible design, before loading libegl.so by EGL in the first operating system and libgles.so by OpenGLES in the first operating system, the method further comprises: responding to a second user operation, and creating a surface by the first operating system, wherein the surface is used for bearing graphic data of a second application; wherein the second application is running in the first operating system.

In one possible design, before loading libegl.so by EGL in the first operating system and libgles.so by OpenGLES in the first operating system, the method further comprises: responding to a second user operation, and sending a second request to the gateway service by the first operating system, wherein the second request is used for requesting to create a surface; the second operating system receiving a second request from the gateway service; responding to the second request, the second operating system creates a surface and sends the surface to the gateway service; the first operating system receives a surface from the gateway service. Based on the design, the operating system in the semi-container can acquire a surface from the operating system outside the semi-container to draw the graph.

In one possible design, after loading libegl.so by EGL in the first operating system and libgles.so by OpenGLES in the first operating system, the method further includes, after completing the rendering operation of the graphics: the first operating system sends the rendered surface to the second operating system; the second operating system performs operations on the rendered surface composition and send display.

In one possible design, before loading libegl.so by EGL in the first operating system and libgles.so by OpenGLES in the first operating system, the method further includes: the second operating system generates a vertical synchronization VSYNC signal; the second operating system sends a VSYNC signal to the first operating system.

In one possible design, the method further comprises: in response to a third user operation, the first operating system receives an input event sent by the second operating system from an input channel, which is established by the second operating system.

In a second aspect, the present application provides an electronic device having functionality to implement the method as described in the first aspect and any one of the designs. The functions can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the functions described above.

In a third aspect, the present application provides an electronic device that includes a first operating system, a second operating system, and a gateway service. The first operating system is used for executing the method executed by the first operating system in the first aspect and any design, the second operating system is used for executing the method executed by the second operating system in the first aspect and any design, and the gateway service is used for executing the method executed by the gateway service in the first aspect and any design.

In a fourth aspect, the present application provides an electronic device comprising: comprising a processor and a memory coupled to the processor, the memory for storing computer program code, the computer program code comprising computer instructions, the processor reading the computer instructions from the memory to cause the electronic device to perform the method as described in the first aspect and any one of the designs above. The memory may be coupled to the processor or may be separate from the processor.

In one possible design, the electronic device further includes a communication interface operable to communicate with other apparatus. By way of example, the communication interface may be a transceiver, an input/output interface, an interface circuit, an output circuit, an input circuit, a pin or related circuit, or the like.

In one possible design, the electronic device further includes a display screen operable to perform a display operation with the electronic device.

In a fifth aspect, the present application provides a computer readable storage medium comprising a computer program or instructions which, when run on an electronic device, cause the electronic device to perform the method as described in the first aspect and any one of the designs described above.

In a sixth aspect, the application provides a computer program product enabling a computer to carry out the method of the first aspect and any one of the designs described above when the computer program product is run on the computer.

In a seventh aspect, the present application provides a chip system comprising at least one processor and at least one interface circuit, the at least one interface circuit being configured to perform a transceiving function and to send instructions to the at least one processor, when executing the instructions, performing the method as described in the first aspect and any one of the designs above.

It should be noted that the technical effects of any one of the designs in the second aspect to the seventh aspect may be referred to the technical effects of the corresponding design in the first aspect, and will not be described herein.

Drawings

Fig. 1 is a schematic diagram of a multi-system compatible scenario provided in an embodiment of the present application;

fig. 2 is a schematic diagram of a multi-system compatible scenario provided in an embodiment of the present application;

Fig. 3 is a schematic diagram of an electronic device according to an embodiment of the present application;

fig. 4 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present application;

FIG. 5A is a schematic diagram of a multi-system compatible framework according to an embodiment of the present application;

FIG. 5B is a schematic diagram of a multi-system compatible framework according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a first operating system in a clipping semi-container according to an embodiment of the present application;

Fig. 7 is a schematic diagram of an operation mode of an electronic device according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a scenario of interaction between operating systems inside and outside a semi-container of an electronic device according to an embodiment of the present application;

FIG. 9 is a schematic diagram of an interface provided in an embodiment of the present application;

FIG. 10 is a schematic diagram illustrating a process of an operating system in a semi-container calling services in an operating system outside the semi-container according to an embodiment of the present application;

Fig. 11A is a schematic diagram of functions included in a gateway service according to an embodiment of the present application;

FIG. 11B is a schematic diagram of creating an input event transmission channel through a WMS according to an embodiment of the present application;

FIG. 12 is a schematic diagram of a process for creating a main window according to an embodiment of the present application;

FIG. 13 is a schematic diagram of a process for managing child windows according to an embodiment of the present application;

FIG. 14 is a schematic diagram of a software architecture related to graphics implementation according to an embodiment of the present application;

FIG. 15A is a schematic diagram of an ABI compliant scheme provided by an embodiment of the present application;

FIG. 15B is a schematic diagram of another ABI compliant scheme provided by an embodiment of the present application;

FIG. 16 is a schematic diagram of a linker namespace in accordance with an embodiment of the present application;

FIG. 17 is a schematic diagram of a process for implementing graphics according to an embodiment of the present application;

FIG. 18 is a flowchart of a method for implementing graphics according to an embodiment of the present application;

FIG. 19 is a schematic diagram of another graphics implementation process provided by an embodiment of the present application;

fig. 20 is a process schematic diagram of an ACE-based graphics implementation method according to an embodiment of the present application;

FIG. 21 is a schematic diagram illustrating a VSYNC signal transmission process according to an embodiment of the present application;

FIG. 22 is a schematic diagram of a graphics-related process provided by an embodiment of the present application;

FIG. 23 is a schematic diagram of another graphics-related process provided by an embodiment of the present application;

fig. 24 is a flow chart of a window implementation method under multiple systems according to an embodiment of the present application;

fig. 25 is a schematic structural diagram of an electronic device according to an embodiment of the present application;

fig. 26 is a schematic structural diagram of a chip system according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application are described below with reference to the accompanying drawings in the embodiments of the present application. In the description of embodiments of the application, the terminology used in the embodiments below is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the specification of the application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include, for example, "one or more" such forms of expression, unless the context clearly indicates to the contrary. It should also be understood that in the following embodiments of the present application, "at least one", "one or more" means one or more than two (including two).

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise. The term "coupled" includes both direct and indirect connections, unless stated otherwise. The terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated.

In embodiments of the application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

In some embodiments, the electronic device operating system may employ a layered architecture that divides the software into several layers, each layer having distinct roles and branches, with the layers communicating via software interfaces. For example, as shown in fig. 1, the software architecture of the electronic device includes a driver kernel layer, a system service layer, and an application layer.

Optionally, one or more operating systems may be configured in the electronic device, where compatibility between multiple operating systems is required in the case that multiple operating systems are configured in the electronic device. Wherein the operating system of the electronic device includes, for example, but not limited to, androidEtc.

At present, a cross-operating system compatibility scheme is generally based on different layers and interfaces of software to ensure compatibility. Among other compatible schemes, for example, application programming interface (application programming interface, API) bridging schemes, container schemes, virtual machine schemes.

For example, as shown in fig. 1, in the API bridging scheme, based on an application layer, compatibility of different operating systems is ensured by bridging API interfaces of each application program between different operating systems. In the application development process, the corresponding API interfaces need to be developed one by one for different operating systems to achieve compatibility. This also results in lower compatibility and higher complexity of the API bridging scheme.

For another example, as shown in fig. 1, in the container scheme, a container for running different operating systems is created, and compatibility of the different operating systems is ensured through a driving interface corresponding to a system service layer of the operating system in the different container. In this scheme, although compatibility can be improved, operating systems based on a driving interface are compatible, and overhead such as performance memory is high, which is not beneficial to operation of the electronic device.

For another example, as shown in fig. 1, in the virtual machine scheme, by creating a virtual machine, compatibility of different operating systems is ensured based on a virtual machine interface corresponding to a driving kernel layer. In this approach, the electronic device needs to rely on hardware to enable compatibility of different operating systems.

In some examples, the software layered architecture of the operating system further includes an application runtime, where the application runtime is configured to provide a running environment of an application in the operating system, record an application running state, and so on. Alternatively, as shown in FIG. 2, the application runtime may be between the system service layer and the application layer.

The embodiment of the application provides a multi-system compatible method. Under the condition that the electronic equipment is configured with a plurality of operating systems, a semi-container is created, and the operating systems in the semi-container and the operating systems outside the semi-container are compatible with each other through a system interface or a core interface between application runtimes in respective software.

The semi-container may also be referred to as a first container.

Wherein, the operating system can reserve the respective complete application running time capability, thereby realizing 100% compatibility of the interface. In this way, under the condition that different operating system applications are installed in the electronic device, the user cannot feel the difference when using the applications of the different operating systems, and therefore better electronic device operating system compatibility experience is obtained.

And, as shown in fig. 2, when the application runs on the system service layer, interaction between different operating systems inside and outside the semi-container is realized through a system interface or a core interface between the application run, so that the application of the operating system inside the semi-container can multiplex the system service in the operating system outside the semi-container. Therefore, the expense of the semi-container can be reduced by cutting off the system service which can be reused by the operating system in the semi-container.

Alternatively, the multi-system compatible method provided by the embodiment of the application can be applied to the electronic device 100. For example, as shown in fig. 3, the electronic device 100 includes, but is not limited to, a mobile phone 31, a Personal Digital Assistant (PDA) 32, a personal computer (personal computer, PC) 33, a Laptop computer (Laptop), a large screen display device, a wearable device, an in-vehicle device, an artificial intelligence (ARTIFICIAL INTELLIGENCE, AI) device, and the like. Operating systems installed on electronic device 100 include, but are not limited toOr one or more of the other operating systems. The application is not limited by the particular type of electronic device 100, nor by the number of operating systems installed.

Illustratively, fig. 4 shows a hardware architecture diagram of the electronic device 100.

As shown in fig. 4, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, a charge management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, keys 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identity module (subscriber identification module, SIM) card interface 195, etc.

It should be understood that the illustrated structure of the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the application, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (IMAGE SIGNAL processor, ISP), a controller, a video codec, a digital signal processor (DIGITAL SIGNAL processor, DSP), a baseband processor, and/or a neural-Network Processor (NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-INTEGRATED CIRCUIT, I2C) interface, an integrated circuit built-in audio (inter-INTEGRATED CIRCUIT SOUND, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

The charge management module 140 is configured to receive a charge input from a charger. The charger can be a wireless charger or a wired charger.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 to power the processor 110, the internal memory 121, the display 194, the camera 193, the wireless communication module 160, and the like.

The wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (WIRELESS FIDELITY, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation SATELLITE SYSTEM, GNSS), frequency modulation (frequency modulation, FM), near field communication (NEAR FIELD communication, NFC), infrared (IR), etc., applied to the electronic device 100.

In some embodiments, antenna 1 and mobile communication module 150 of electronic device 100 are coupled, and antenna 2 and wireless communication module 160 are coupled, such that electronic device 100 may communicate with a network and other devices through wireless communication techniques.

The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ a Liquid Crystal Display (LCD). In some embodiments, the electronic device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.

The camera 193 is used to capture still images or video. In some embodiments, electronic device 100 may include 1 or N cameras 193, N being a positive integer greater than 1.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to enable expansion of the memory capabilities of the electronic device 100. The external memory card communicates with the processor 110 through an external memory interface 120 to implement data storage functions. For example, files such as music, video, etc. are stored in an external memory card.

The internal memory 121 may be used to store computer executable program code including instructions. The internal memory 121 may include a storage program area and a storage data area. The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 100 (e.g., audio data, phonebook, etc.), and so on. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universal flash storage, UFS), and the like. The processor 110 performs various functional applications of the electronic device 100 and data processing by executing instructions stored in the internal memory 121 and/or instructions stored in a memory provided in the processor.

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or a portion of the functional modules of the audio module 170 may be disposed in the processor 110. The electronic device 100 may play, record, etc. music through the audio module 170. The audio module 170 may include a speaker, a receiver, a microphone, a headphone interface, an application processor, etc. to implement audio functions.

The sensor module 180 may include a pressure sensor, a gyroscope sensor, a barometric sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

The keys 190 include a power-on key, a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration alerting as well as for touch vibration feedback.

The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.

The SIM card interface 195 is used to connect a SIM card.

In some embodiments, multiple operating systems may be installed in an electronic device, with compatibility between different operating systems being required. In this way, a user can use applications of multiple operating systems with no sense of presence through one electronic device.

For example, the electronic device is provided with two operating systems, which are respectively an operating system a and an operating system B, and fig. 5A shows a system architecture diagram of the electronic device according to an embodiment of the present application.

As shown in fig. 5A (a), an operating system B may run in the semi-container. By way of example, a semi-container may include, but is not limited to, a three-way application of operating system B, a core of operating system B, etc. The three-way application of the operating system B may refer to other applications than the system application of the operating system B, such as an application downloaded from an application market or the like. Wherein "the kernel of operating system B" may also be described as "the running environment of the application of operating system B". Illustratively, the kernel of operating system B may provide an API interface, programming framework, etc. for the three-way application of operating system B.

Operating system a may run outside of the semi-container. Illustratively, the semi-container may include, but is not limited to, an application of operating system A (e.g., the application may include a system application and/or a third party application, etc.), a runtime environment of operating system A, a system capability of operating system A, etc. Alternatively, the introduction to the operating system A's operating environment may refer to the introduction to the operating system B's operating environment.

By way of example, the system capabilities of operating system A may include hardware capabilities, software capabilities, and the like. During the running process, the three-party application in the operating system B in the semi-container can call the system capability of the operating system A through the system interface or the core interface between the operating system B and the operating system A. That is, operating system B within the half-container implements a portion of the capability of operating system A outside of the half-container, such that operating system B within the half-container may no longer configure this portion of the capability, thereby reducing container overhead.

For example, operating system A is an android system and operating system B is a hong Monte system. Therefore, based on the electronic equipment with larger stock of android systems at present, a semi-container for running the hong Monte system can be configured in the electronic equipment so as to realize that the electronic equipment supports double operating systems.

In fig. 5A, (a) illustrates a system architecture of an electronic device having two operating systems, taking an operating system outside a half-container as an operating system a and an operating system inside the half-container as an operating system B. It should be understood that the operating system within the half-container and the operating system outside the half-container may also be interchanged.

For example, as shown in fig. 5A (B), operating system a may run inside the half-container and operating system B may run outside the half-container. For the description of each module in fig. 5A (b), reference may be made to the description of the corresponding module in fig. 5A (a).

In the system architecture shown in fig. 5A (a) and (B), the operating system a and the operating system B may be isolated by a semi-container technology. It will be appreciated that semi-container technology may partition resources of different operating systems into isolated groups to better balance conflicting resource usage requirements among the isolated groups. In some embodiments, the operating systems located within the half-containers may all invoke the system capabilities of the operating systems located outside the half-containers to achieve normal operation of the operating systems. As shown in fig. 5A (a), operating system B may call the system capabilities of operating system a, or operating system a may call the services of operating system B. As shown in fig. 5A (B), operating system a may invoke system capabilities of operating system B. Or operating system B may also invoke the services of operating system a.

For another example, the electronic device may be provided with two or more operating systems. In the case where the electronic device has two or more operating systems installed, one or more half-containers may be configured in the electronic device. One or more operating systems may be included in the semi-container, and one or more operating systems may be included outside the semi-container.

Taking the electronic device with three operating systems installed as an example, an operating system a, an operating system B, and an operating system C respectively, fig. 5B shows a system architecture diagram of another electronic device according to an embodiment of the present application.

As shown in fig. 5B (a), the electronic apparatus is configured with one half-container. Operating system B may run inside the half-container and operating system a and operating system C may run outside the half-container. Alternatively, compatibility between multiple operating systems outside the semi-container may be achieved based on existing operating system compatibility schemes.

As shown in fig. 5B (B), the electronic apparatus is configured with two half-tanks, half-tank 1 and half-tank 2. Operating system B may run inside half-container 1, operating system C may run inside half-container 2, and operating system a may run outside half-container.

As shown in fig. 5B (c), the electronic apparatus is configured with two half-tanks, half-tank 1 and half-tank 2, and half-tank 1 includes half-tank 2. Operating system B may run inside half-container 1, operating system C may run inside half-container 2, and operating system a may run outside half-container.

In this way, by configuring the half-container, even when two or more operating systems are installed in the electronic device, compatibility between different operating systems can be achieved.

In each scenario shown in fig. 5B, the communication manner between the operating systems inside and outside the semi-container and between different semi-containers and the module description in the operating system may be referred to the communication manner between the operating systems inside and outside the semi-container and the module description in the operating system in the scenario shown in fig. 5A. And will not be described in detail.

The following describes in detail a multi-system compatible method provided by the embodiment of the present application, taking an example that an electronic device supports dual operating systems.

The software system of the electronic device may employ a layered architecture, an event driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. Taking the operating system in the semi-container as a first operating system (e.g., the hong-mo system), the operating system outside the semi-container as a second operating system (e.g., the android system), which all adopt a hierarchical architecture as an example, the software structure of the electronic device 100 is illustrated.

Fig. 6 is a software structure of the electronic device 100 according to the embodiment of the present application.

The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface.

As shown in fig. 6 (a), the second operating system is divided into five layers, namely, an application layer, a framework library (framework library), a framework service (framework services), a hardware abstraction layer (hardware abstract layer, HAL), a kernel and a driver layer (or referred to as a kernel layer and a driver layer) from top to bottom.

The application layer includes a series of application packages (or application packages) of the second operating system, such as applications (not shown in the figure) of a camera, a gallery, a calendar, a call, a map, and the like.

The framework library may include various functional modules, such as: surface manager (surface manager), media library (Media Libraries), three-dimensional graphics processing library (e.g., openGL ES), 2D graphics engine (e.g., SGL), etc. (not shown).

The surface manager is used to manage the display subsystem and provides a fusion of 2D and 3D layers for multiple applications.

Media libraries support a variety of commonly used audio, video format playback and recording, still image files, and the like. The media library may support a variety of audio and video encoding formats, such as MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The 2D graphics engine is a drawing engine for 2D drawing.

Optionally, the framework library includes an application runtime of the second operating system. The application runtime is responsible for scheduling and managing the second operating system, and provides a running environment for the application of the second operating system.

The framework services may provide APIs and programming frameworks for application programs of the application layer. The framework services include some predefined functions. For example, the framework services may include a window manager, a content provider, a view system, a telephony manager, a resource manager, a notification manager, and the like.

The window manager is used for managing window programs. The window manager can acquire the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make such data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebooks, etc.

The view system includes visual controls, such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, a display interface including a text message notification icon may include a view displaying text and a view displaying a picture.

The telephony manager is used to provide the communication functions of the electronic device 100. Such as the management of call status (including on, hung-up, etc.).

The resource manager provides various resources for the application program, such as localization strings, icons, pictures, layout files, video files, and the like.

The notification manager allows the application to display notification information in a status bar, can be used to communicate notification type messages, can automatically disappear after a short dwell, and does not require user interaction. Such as notification manager is used to inform that the download is complete, message alerts, etc. The notification manager may also be a notification in the form of a chart or scroll bar text that appears on the system top status bar, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, a text message is prompted in a status bar, a prompt tone is emitted, the electronic device vibrates, and an indicator light blinks, etc.

The hardware abstraction layer is an interface layer between the operating system kernel and the hardware circuitry, which encapsulates the underlying hardware drivers, providing a generic interface for calling drivers to the framework layer.

The kernel and driver layers are layers between hardware and software. The kernel and driver layer may include various drivers such as: display driving, camera driving, audio driving, sensor driving, etc.

As shown in fig. 6 (a), the first operating system in the semi-container may also employ a layered architecture. The first operating system is divided into five layers, namely an application program layer, an application runtime, a system interface (SYSTEM API)/core interface (core API), an application program framework layer, a kernel and a driving layer from top to bottom.

The application program layer comprises a series of application program packages of the first operating system, such as third-party applications, system applications and the like.

The application runtime is responsible for scheduling and managing the first operating system, and provides a running environment for the application of the first operating system.

A system interface/core interface for supporting interaction between a first operating system within the semi-container and a second operating system outside the semi-container. For example, a third party application of a first operating system within a semi-container invokes a service provided in a framework service in a second operating system outside the semi-container through a system interface/core interface through a gateway service outside the semi-container.

The application framework layer provides APIs and programming frameworks for application programs of the application layer. The application framework layer includes a number of predefined functions. As shown in fig. 6 (a), the application framework layer may include a window service (or window MANAGER SERVICE, WMS)), a hardware service, a package management service, a task management service, a distributed service, a security authentication service, and the like.

The window service may be used to manage the window program. Such as: creation of windows, destruction, management of window locations, and so forth.

The package management service may be used to parse and install application packages. If the first operating system is a hong Monte System, the package management service may be used to manage (HarmonyOS ability package, HAP) packages. In view of the fact that these services are all of the prior art, reference is made to the description of the related art for specific details.

For the description of the kernel and the driver layer, reference may be made to corresponding descriptions of the kernel and the driver layer of the second operating system.

In some embodiments, a portion of the services (or capabilities) of a first operating system located within a semi-container are trimmed, the trimmed services being provided with capabilities by a second operating system outside of the semi-container. In this way, the container overhead is reduced while the operation system in the semi-container is guaranteed to run. That is, the first operating system running within the semi-container may contain a portion of all the services that it supports.

Illustratively, fig. 6 (b) shows a schematic software architecture after clipping out a part of services contained in the first operating system.

Optionally, the application package management manner in different operating systems is different, for example, the hong-Meng system package management service is used for managing HAP packages, and is different from the package management service of the android system. Then, in the case of the hong-and-Monte system and the android system inside and outside the semi-container, respectively, packet management services of the operating system in the semi-container need to be reserved.

Optionally, the task management service in different operating systems is also required to keep the task management service of the operating system in the semi-container because the execution entrance and the component management mode for executing different tasks are different.

Optionally, the security sensitivity of the operating system is higher, isolation is needed, and in order to ensure the running security of different operating systems, the security authentication service of the operating system in the semi-container needs to be reserved. In addition, to ensure storage security, the storage services of the operating system within the semi-container (not shown in FIG. 6) may also be reserved.

Alternatively, as shown in fig. 6 (a), in the case where the first operating system is a hong-and-Monte system, the distributed service may exist in the first operating system as a feature service of the first operating system. Thus, in the case where the operating system within the semi-container is a hong Monte system, its distributed services are preserved. That is, during the clipping of the services provided by the first operating system in the semi-container, the feature services of the second operating system are retained, which cannot be reused.

To sum up, as shown in fig. 6 (b), the services that the first operating system is cut off include: system application, kernel and driving layer, window service, hardware service. The reserved services include: packet management services, task management services, security authentication services, distributed services, etc.

It will be appreciated that the services cut-out shown in fig. 6 (b) are merely illustrative, and a developer may decide which services to cut-out according to the service conditions, actual needs, etc. included in the first operating system and the second operating system. And as future architectures evolve, more or fewer or different services than shown in fig. 6 (b) may also be tailored.

In some embodiments, the software structures shown in (a), (b) of fig. 6 may also include an application container (application container), gateway services (GATEWAY SERVICE), container management (container manager) modules, and the like. The application container, the gateway service and the container management module can all run outside the semi-container.

The application container can be used for mapping the application in the first operating system in the second operating system so that the second operating system can uniformly manage the application in the electronic device. By way of example, the application container may include an interface to a package management service, an interface to a task management service, an interface to a window management service, and the like. Wherein the interfaces of each service can be used to invoke the corresponding service.

Gateway services may be used to enable communication across containers. Alternatively, the gateway service may bridge the service cut-down when the first operating system uses the service cut-down to the service corresponding to the second operating system, so that the first operating system can normally use the service. Illustratively, the gateway service may implement cross-container communication based on inter-process communication (IPC) technology. Of course, it may also implement cross-container communication based on other techniques, which embodiments of the present application are not particularly limited in this regard.

The container management module may be used to manage the semi-containers, such as to manage the lifecycle of the semi-containers, control the starting, stopping, etc. of the semi-containers via the semi-container engine.

It should be understood that the layers and the names of the layers shown in fig. 6 are only exemplary, and other division manners or naming manners are also possible in practical application. The software structure provided in the embodiment of the present application is only exemplary, and other division modes are also possible in practical application, which is not limited in this aspect of the present application.

In some embodiments, as shown in fig. 7, the operating mode of the electronic device 100 having the software structure shown in fig. 6 (b) may include a collaborative mode, a service (service) bridge mode, a library (library) bridge mode.

As shown in fig. 7 (a), the collaboration mode may refer to that some services (such as service a) may be included in a first operating system in the semi-container and a second operating system outside the semi-container at the same time, and these services need to be cooperatively managed on both inner and outer sides of the semi-container. Taking the service a as the package management service as an example, the installation, update and unloading of the first operating system application in the semi-container are managed by the package management service in the semi-container, and synchronous information is needed to be managed in cooperation with the package management service outside the semi-container. In some embodiments, these services that need to work in tandem inside and outside of the semi-container may be referred to as collaboration services.

As shown in fig. 7 (b), the service bridging mode may refer to that a part of services (such as service b) are clipped in the first operating system located in the semi-container, and when the clipped services are called by the first operating system in the semi-container, the call needs to be bridged to the corresponding services in the second operating system outside the semi-container to obtain the corresponding capability. Taking service b as a window management service for example, when a first operating system application in the semi-container needs to create a window, as the window management service in the semi-container is cut, the call of the application is bridged to the window management service outside the container, and the result of the call is returned to the application in the semi-container.

It will be appreciated that the service bridge mode is different from the API bridge mode. An API bridge mode refers to all APIs that a second operating system outside the semi-container needs to implement one by one for a first operating system inside the semi-container. That is, the APIs included in the first operating system within the semi-container are implemented in the second operating system outside of the semi-container. The service bridging mode refers to that the API in the first operating system in the semi-container is still implemented in the first operating system in the semi-container, and the first operating system in the semi-container is bridged to the corresponding system service implementation in the second operating system outside the semi-container when some system service is called. Based on the design, compared with an API bridging scheme, the service bridging scheme provided by the embodiment of the application does not need to realize the APIs included in the first operating system in the semi-container one by one in the second operating system outside the semi-container, and reduces the complexity of system compatibility.

As shown in fig. 7 (c), a library bridge mode may refer to that a first operating system located in a semi-container may map library 1 located in a second operating system to use by the first operating system when calling library 2 (e.g., a binary file, etc.). In some embodiments, the programming language of library 2 is inconsistent with the programming language of library 1, and the programming language of library 1 is consistent with the programming language of the underlying driver of the first operating system, thus mapping library 2 to library 1, which avoids the problem of incompatibility of the application binary interface (application binary interface, ABI) caused by the use of the underlying driver of the second operating system by the first operating system.

By way of example, in connection with the system architecture shown in fig. 5A (a), taking the operating system a as a hong-mo system and the operating system B as an android system as an example, fig. 8 shows a software architecture diagram of still another electronic device 100 according to an embodiment of the present application.

As shown in FIG. 8, the hong system is running inside the semi-container and the android system is running outside the semi-container. Among them, third party applications, application framework layers, collaboration services, IPC, etc. of the hong system are included in the semi-container. By way of example, collaborative services may refer to services included in the hong system that are functionally identical or similar to those included in the android system, such as package management services, and the like. The IPC can be used for realizing the communication function with the android system outside the container by adopting the IPC technology.

It will be appreciated that the cut services included within the semi-containers shown in fig. 8 are not included in the hong system as they have been cut away. By way of example, the clipped service may include, but is not limited to, a window service, a hardware service, etc., such as that shown in fig. 6 (a).

The semi-container comprises a system application, an application program framework layer, a container management module, an Android open source code item (Android open source project, AOSP) service, a gateway service, IPC, a container engine (or a semi-container engine), a hardware abstraction layer, a kernel and driving layer, a hardware peripheral, a hong Meng core construction (Harmony core build) and the like. Reference is made to the description of the corresponding modules shown in fig. 6 for the description of the system applications, application framework layers, container management modules, hardware abstraction layers, kernels and driver layers therein.

AOSP services, i.e. services included in the android system, such as: window management services, package management services, and the like. Among other things, AOSP services may include a container loader (loader) and collaboration services. The container loader may be used to download, install, update semi-containers, etc. The collaborative service may refer to the same services included in the android system as in the hong system, such as a package management service, etc.

The gateway service may include a bridge adapter (adapter) and a collaboration adapter. The bridging adapter can be used for bridging the cut service to the corresponding service in the operating system (such as android system) outside the semi-container when the operating system (such as hong Mongolian system) inside the semi-container calls the cut service, so as to realize successful call of the operating system inside the semi-container to the service. As shown by the dashed line 1 in FIG. 8, when the application framework layer of the hong-and-Monte system invokes a clipped service, the call can be bridged to the corresponding service of the android system by the bridging adapter. As shown by the dashed line 2 in fig. 8, the collaboration adapter may enable a common management of collaboration services within the semi-container with collaboration services outside the semi-container.

The IPC can be used for realizing the communication function with the hong Mongolian system in the semi-container by adopting the IPC technology. The container engine may be used to start or stop the operation of the semi-containers. By way of example, the hardware peripherals may include, but are not limited to, motors, cameras, WIFI, global positioning systems (global positioning system, GPS), GPUs, and the like.

Hong Meng core building may provide clipping capability and building framework for hong Meng systems. And constructing a Core mirror image of the hong Monte system according to the cut hong Monte system code engineering. Illustratively, the HongMonte System Core image may include portions of the HongMonte System other than third party applications included in a semi-container such as that shown in FIG. 8.

Based on the system compatibility scheme described in the above embodiment, on one electronic device, compatible coexistence of multiple operating systems may be implemented, for example: android systems and hong Meng systems. On the electronic device, applications of different operating systems may run normally. And, the application installation packages of different operating systems can be directly installed without secondary adaptation packaging. For a developer of a certain operating system, the electronic equipment can be directly used for development and debugging. And, based on the compatibility scheme of the semi-containers, without installing different applications, such as: only android applications, or only hong Monte applications, may reduce the impact on the system performance of the electronic device. Multiplexing of hardware ecology can also be implemented, such as: the hong Mongolian system can multiplex the hardware ecology of the android system. When a user uses an application within a semi-container, a non-sensory experience can be achieved.

Taking an example that an android system and a hong-Meng system are simultaneously installed on a mobile phone as an example, FIG. 9 shows some interface effect schematic diagrams provided by the embodiment of the application.

Illustratively, as shown in fig. 9 (a), the handset displays a main interface 900 (or desktop 900). Icons of Android applications, which may be used to implement functions of the Android applications, such as icons 901 of browser applications, may be displayed simultaneously in the main interface 900. And icons of Harmony applications that can be used to implement the functionality of Harmony applications, such as icons 902 of video hong Mongolian applications, and the like. That is, android applications as well as Harmony applications may share desktop functions.

As shown in fig. 9 (b), the handset displays a multitasking center interface 910. An Android application running interface, such as browser application running interface 911, is included in the multitasking center interface 910. And a runtime interface for a Harmony application, such as runtime interface 912 for a video hong Mongolian application. That is, android applications as well as Harmony applications may share multitasking center functions.

As shown in fig. 9 (c), the handset displays an application management interface 920. Options for Android applications, such as option 921 for browser applications, may also be included in the application management interface 920, which may be used to implement management of Android applications. And options for Harmony applications that may be used to enable management of Harmony applications, such as option 922 for video Hongyuang applications, and the like. That is, android applications as well as Harmony applications may share application management functions.

The implementation of the window and the graph will be described based on the semi-container scheme according to the embodiment of the present application. In the following embodiments, the operating system in the semi-container is taken as a hong Monte system, and the operating system outside the semi-container is taken as an android system for example.

It can be understood that the technical scheme provided by the embodiment of the application is also applicable to the case that the operating systems inside and outside the semi-container are other operating systems.

The following describes the implementation of the window.

In some embodiments, the window services included in the buddha system are clipped. Thus, windows in the hong-and-Monte system can be managed by the window management service in the android system. Of course, in the case that the window service in the hong Monte System is not cut, the window in the hong Monte System may be managed by the window service in the hong Monte System, which will not be described in detail in the present application.

By way of example, FIG. 10 illustrates a software architecture associated with a window implementation provided by an embodiment of the present application. As shown in fig. 10, the window API (or framework API of the window) of the hong system remains in the hong system. It is understood that a window API refers to a series of APIs that relate to window implementation (e.g., window definition, window creation, etc.).

WMSs included in AOSP services may be used to manage windows in android systems as well as windows in hong-and-mong systems. By way of example, functions of the WMS may be such as creating, destroying windows, managing the location, size, etc. of windows, passing surfaces (surfaces) corresponding to windows to a budgeting system, etc.

The WMSs included in the gateway service are WMSs-corresponding adapters that may be used to bridge the WMSs in AOSP services, implementing the invocation of WMS functions. Exemplary, as shown in fig. 11A, the functions of the bridged WMS include, but are not limited to, obtaining window attributes (e.g., window type (type), window Identification (ID), window name (name), etc.), window focus, window mode (mode), managing window lifecycles, e.g., creating, or displaying, or hiding, or destroying windows, etc., adjusting window size, querying window location and size, binding windows and input events, converting and transmitting input events, etc. Of these, fig. 11A shows only a part of the functions.

In some examples, WMSs included in the gateway service may also be described as inputs (inputs), which may also be used to bridge WMSs in AOSP services to implement the relevant functions of the input event.

By way of example, FIG. 11B illustrates a schematic diagram of creating an input event transport (or distribution) channel through a WMS, in accordance with an embodiment of the present application. As shown in fig. 11B, the window API in the hong system may call the WMS in the Android system through the input adapter in the gateway service to implement the establishment of the input event transmission channel. After the establishment is completed, the input event transmission channel can be utilized to distribute the input event. Such as: an input event of a hardware abstraction layer in the android system can be distributed to a ArkUI framework of an application process in the hong and Monte system by using the input event transmission channel established by the input event transmission channel through an input call (InputDispatcher) service included in AOSP services. It is understood that ArkUI is a set of User Interface (UI) development frameworks that build a distributed application interface.

In some embodiments, the gateway service may also be responsible for the backhaul of window events. Such as a gateway service may pass window maximize events, minimize events, close events, window size change events, etc., back to the operating system within the semi-container.

Such as: upon detecting an operation performed by a user to maximize an application window of the buddhist system, such as a click operation on a maximize button corresponding to the application window, responsive to the operation, a mode of the application window is modified to a full-screen mode. The android system may communicate this maximized event back to the meta-capability cross-platform operating environment (ability cross-platform environment, ACE) of the hong system through the gateway service. Among them, ACE is a UI framework that can provide interface development capabilities for applications,

For another example: when detecting the operation of the application window of the minimize hong Monte system, such as the click operation of the minimize button corresponding to the application window, the application window is returned to the background operation in response to the operation. The android system may communicate this minimized event back to the ACE of the hong system through the gateway service.

For another example: when an operation of closing an application window of the hong Monte system, such as a click operation of a close button corresponding to the application window, performed by a user is detected, the application window is closed in response to the operation. The android system can pass this minimized event back to the window API of the hong system through the gateway service.

For another example: when the application window of the hong-and-Monte system is switched in modes such as full screen, floating window and split screen, or when the folding state and unfolding state of the folding screen product are switched, the size of the application window may be changed. The android system can also transmit the window size change event, window size, etc. back to the ACE of the hong system through the gateway service.

For the description of other modules in fig. 10, reference is made to the description of corresponding modules in the structure shown in fig. 8.

In some embodiments, as shown in FIG. 10, when the window API calls a window service, the window service has been clipped as a result of the hong system. Thus, the functionality of the windows in the hong system may be achieved by bridging to the adapter corresponding to the WMS in the gateway service, and invoking AOSP the WMS in the service through the adapter.

The following describes the process of a hong system invoking the functionality of a WMS in the android system in connection with several specific examples.

In some examples, the hong system may enable creation of the primary window by invoking a WMS in the android system. It is understood that the main window may refer to a top-level window that interacts with the user for a long period of time.

By way of example, FIG. 12 illustrates a schematic diagram of a process for creating a primary window provided by an embodiment of the present application. As shown in FIG. 12, when there is a need to create a main window for an application in the hong system, a capability is first created (ability) and then a scene is initialized (scene). At this point, the hong system may forward a first instruction to the WMS of the android system via the gateway service, the first instruction being usable to request the WMS to create a primary window for it. Such as the first instruction may be a CreateWindow instruction, or the like. The hong and Monte System may then initialize the main window, setting the interface layout of the window through the ACE. At this time, the hong system may forward a second instruction to the WMS of the android system through the gateway service, and the second instruction may be used to learn the created window ID, etc. Such as the second instruction may be, for example, the GetSurfaceNode instruction. In this example, the WMS may be used to manage and map the window ID of the primary window created by the WMS for the hong system, and so on. The hong Mongolian system may also manage and map its own ability tokens (token), etc.

In other examples, the hong-and-Monte system may implement management of child windows by invoking WMSs in the android system. Such as: creating a child window, displaying a child window, hiding a child window, etc.

Fig. 13 is a schematic diagram illustrating a process of managing child windows according to an embodiment of the present application. As shown in fig. 13, for example: when there is a window already existing in the hong-and-Monte system and there is a need for creating a window for an application in the hong-and Monte system, a third instruction may be forwarded to the WMS of the android system through the gateway service, and the third instruction may be used to request the WMS to create a child window for the WMS. Such as the third instruction may be, for example, the newPhoneWindow instruction. For another example: when there is a need to display a child window in the hong-mo system, a third instruction may be forwarded to the WMS of the android system through the gateway service, and the third instruction may be a display (show) command, for example. For another example: when there is a need to hide the child window in the hong-and-Monte system, a third instruction may be forwarded to the WMS of the android system through the gateway service, and the third instruction may be a hide (hide) command, for example.

The following description is directed to related implementations of the graphics. It is to be appreciated that in embodiments of the present application, the graphics may also be described as a graphical user interface (GRAPHICAL USER INTERFACE, GUI), images, image frames, or the like.

In a semi-container solution such as that shown in FIG. 5A, the operating system within the semi-container and the operating system outside the semi-container may share the system capabilities of the operating system outside the semi-container, including the underlying drive, etc. However, when certain capabilities are used by the operating system within the semi-container, these capability-loaded library files are inconsistent with the written language of the system capabilities of the operating system outside the semi-container, which can lead to problems of ABI incompatibility.

In connection with the semi-container scheme shown in fig. 6 (b), the use of graphics capability by a hong-and-Monte system is exemplified. It is understood that graphics capability may refer to some services that may be used in a graphics implementation. The hong-Monte and android systems may share the system capabilities of the android system, such as drivers including, but not limited to, hardware abstraction layers, kernel layers, etc. These driver authoring languages may not be consistent with those of the graphics capability loaded driver libraries (e.g., libegl. So) of the hong system. It is understood that inconsistencies may be understood as incompatibilities. Such as: the underlying drivers in android systems are written based on bionic C libraries, while the hong-Monte-Card system loaded driver libraries are written based on musl C libraries. Therefore, in the process of graphics implementation, two incompatible writing languages are used in the same process, so that conflicts can occur when accessing common resources, for example, due to inconsistent read-write strategies, when the two incompatible writing languages are used in a thread local storage (thread local storage, TLS) area of a thread, the data of the other party can be mutually covered. That is, this may lead to problems of ABI incompatibility.

While the programming language adopted by the driver library of the hong Mongolian system is consistent with the programming language of the underlying driver. It is to be understood that consistent is to be understood as compatible, but does not represent that the two written languages are identical. Thus, in some embodiments, the graphics capability loaded driver libraries in the hong system may be bridged to driver libraries in the android system to address the problem of ABI incompatibility.

By way of example, FIG. 14 illustrates a software architecture associated with a graphics implementation provided by an embodiment of the present application.

As shown in FIG. 14, the hong system includes a graphics module that can be used to implement a range of graphics-related functions, such as: drawing, rendering, etc. In some examples, for graphics capabilities that are clipped in the hong system, it may bridge the graphics capabilities of the android system to the hong system use through a graphics API bridge module, i.e., the service bridge mode shown in fig. 7 (b). In other examples, for graphics capabilities that present ABI compatibility issues, such as including but not limited to local windows (nativewindow), vertical synchronization (vertical synchronization, VSYNC), libEGL, libGLES, etc., these graphics capability loaded driver libraries may bridge to driver library usage in the android system. Wherein the local window may be used for connection OpenGLES as well as the local window system. VSYNC may be used to trigger the drawing of a frame of graphics. libEGL can be used to build the rendering environment of libGLES and libGLES can be used to implement rendering of graphics. For example: android side drivers (i.e., driver libraries of the android system) may be mapped for use by the hong system through a library bridging mode such as that shown in fig. 7 (c).

The HWC included in AOSP is the interface to invoke the hardware synthesizer (hardware composer, hwcomposer). The hardware synthesizer is a module of a HAL layer for window (or layer) synthesis and display of the android system, and provides hardware support for surface synthesis (SurfaceFlinger) services.

For the description of the other modules shown in fig. 14, reference is made to the description of the corresponding modules in the structure shown in fig. 8.

In some embodiments, to solve the problem of ABI incompatibility, embodiments of the present application provide two schemes that can be used to bridge the driver library of an android system to a hong-and-mong system.

In the scheme 1, the android driving library corresponding to the required android driving library, namely the driving library with the ABI compatibility problem in the hong Monte system, is preset into a semi-container, namely the hong Monte system, and is called libhybris scheme.

For example, taking a file with an android driver library as ". So" end as an example, as shown in fig. 15A, the libhybris scheme specifically includes: and presetting a driving library of the android system into the semi-container by the driving library on which the driving library depends. As shown in fig. 15A, a.so, b.so, c.so, etc. are android drive libraries preset into the half-containers. In some examples, a loader may also be included in libhybris modules that may be used to load the android driver library.

In some embodiments, all of the driver libraries supported by the android system may be preset into the semi-container. In other embodiments, a portion of the library of drivers for the android system, such as the library of drivers required by the hong-and-Monte system, may be preset into the semi-container.

Taking musl C libraries (or musl libraries) as default for processes in the hong-and-Monte system in the semi-container, bionic C libraries (or bionic libraries) as examples for android systems outside the semi-container. It can be understood that bionic C library is one of the base libraries of Android, and is a bridge connecting Android and Linux. The musl C library is a C-standard library built on top of the Linux system call API. In some embodiments, since libhybris modules are based on the hong driver library, such as musl C library, android driver libraries can be packaged, such as "m.so" as "musl: m.so ", i.e., packaging the installation driver library as a hong driver library, to provide an interface for applications in a hong system.

The following describes the process of the Hongmon system invoking these android driver libraries.

In some examples, an application in the hong system may not call a driver library outside of the semi-container before calling the android driver library, and thus an application in the hong system may call the android driver library directly through path 1. In other examples, an application in the hong system may call a driver library outside of the semi-container before calling the android driver library, so that an application in the hong system may call to a driver library outside of the semi-container via path 2 and then call from the driver library outside of the semi-container to the android driver library inside of the semi-container, such as from d.so to a.so, etc.

The drive libraries do not conflict when accessing separate resources. But there may be a conflict in accessing the common resource. Thus, in some embodiments, the libhybris module may monitor the call of each library file included in the android drive library, and when a certain library file is called, if it is determined that a common resource access conflict may occur, the call of the library file may be converted into a call of another drive library by using an android linker (linker) or performing a hook (hook) operation.

The hook operation refers to the operation of hooking the function to be modified, and then replacing the original function with the custom function to enable the program to execute the custom function when running, thereby achieving the purpose of dynamically modifying the software. An android linker can be understood as a linking technology, and specific implementation thereof can refer to implementation in the related art.

As shown in fig. 15A, when an e.so (not shown in the figure) is called from a c.so, if it is determined that a common resource access conflict occurs in the call of the e.so, the call of the e.so may be converted into a call of an h.so by an android linker or performing a hook operation, and the call of the h.so does not have a problem of the common resource access conflict.

Scheme 2 is that calls to the driver libraries with ABI compatibility problems in the hong-mo system are redirected to the corresponding android driver library calls through the linker, which is referred to herein as android library adaptation scheme.

Exemplary, as shown in fig. 15B, the android library adaptation scheme specifically includes: when loading the drive library, an An Zhuo Qudong library linker, such as bionic linker, may be used to load the drive library instead of the default libmusl-ld.so in the hong Meng system. In other embodiments, the android driven linker may have other naming schemes, and it is understood that the name is not limiting of its functionality. In the loading process, the type of the loaded driving library (such as library files ending with ". So" or simply called so files) needs to be judged, and if the driving library is the driving library corresponding to the hong Mongolian system, namely the driving library incompatible with the android system, the call for the driving library is redirected to the corresponding android driving library to be called.

Exemplary, specific redirection procedures include: a library file tree, such as a load so file tree (load so tree), is loaded, i.e., a library file and a library on which the library file depends are loaded. The symbols (e.g., function names, etc.) in the symbol table are then mapped to the memory addresses of the loaded symbols to facilitate recall of the symbols in the corresponding library file, e.g., symbols in the android drive library. This step may also be described as a relocation symbol (relocation symbol) operation. Finally, the connection with the called symbol can be established by executing the hook operation, and the loading of the driver library corresponding to the android is completed. The specific description of the symbol may refer to the description in the related art.

If the driver library is not the driver library corresponding to the hong Mongolian system, namely the driver library compatible with the android system, such as bionic library, the bionic library can be directly called.

In this way, there may be no driver libraries in the semi-container that are incompatible with the android system, such as musl C libraries, and only driver libraries compatible with the android system, such as bionic C libraries, etc., remain.

It can be appreciated that the technical solution provided by the embodiment of the present application is also applicable to native development kits (native development kit, NDK) in the operating system in the semi-container, such as other capabilities besides graphics capabilities, if the ABI compatibility problem exists in the system capabilities of the operating system outside the multiplexed semi-container.

In some scenarios, in an android system, to solve the problem of conflicts in shared libraries (e.g., drive libraries ending with ". So"), a linker namespace (LINKER NAMESPACE) mechanism is employed to isolate shared libraries in different linker namespaces to ensure that libraries with the same library name and different symbols (or functions) do not conflict.

In some embodiments of the present application, the shared library in the operating system outside the semi-container may be called by the operating system inside the semi-container, for example, the shared library in the android system outside the semi-container may be called by the hong system inside the semi-container, for example, the graphics driver library such as bionic C library, and the shared library in the hong system is mostly musl C library-based. That is, there may be multiple shared libraries in the operating system in the semi-container at the same time, for example, there may be multiple shared libraries in the hong-and-Monte system in the semi-container at the same time, for example, bionic C libraries in the android system and musl C libraries in the hong-and Monte system, so that a conflict problem may occur when loading these shared libraries.

Based on this, the embodiment of the present application provides a solution to this conflict, taking as an example that two kinds of shared libraries exist in the hong Monte system, namely musl C library and bionic C library. In some embodiments, two linker namespaces may be employed to isolate musl C libraries and bionic C libraries. Of course, in the case where there are more than two shared libraries in a hong system, more than two linker namespaces may also be employed to isolate the multiple shared libraries.

In some embodiments, the loading of the shared library may be accomplished by a dynamic linker, such as the dynamic linker is responsible for loading the shared library specified in the DT_ NEEDED entry, or the shared library executed by the parameters of dlopen (). During the loading process, the dynamic linker will find the linker namespace where the caller is located and load the relevant dependent into the same linker namespace. If a dynamically linked library fails to load the shared library into a specified linker namespace, the exported shared library is retrieved from the associated linker namespace.

It may be understood that, in the embodiment of the present application, taking an example that two types of shared libraries exist in an operating system in a semi-container, and in a case that more than two types of shared libraries exist in the operating system in the semi-container, the specific implementation may refer to the solution of the embodiment of the present application.

Exemplary, fig. 16 shows a schematic structural diagram of a linker namespace according to an embodiment of the present application. As shown in FIG. 16, the structure includes AOSP namespaces, default namespaces, application namespaces.

Wherein, the AOSP namespaces include the shared libraries of AOSP, namely the shared libraries in the android system. Alternatively, the search path of the shared library may be contained under the { LIB } path. Of course, at 64-bit operating systems, the LIB may also be described as LIB 64. By way of example, table 1 shows examples of some shared libraries under the { LIB } path provided by embodiments of the present application.

TABLE 1

……/${LIB}/egl
	……/${LIB}/hw

As shown in Table 1, shared libraries of egl, hw, etc. in the android system can be stored under the { LIB } path.

The default namespace includes shared libraries in the hong system. Alternatively, the search path of the shared library may be included under the { LIB } path. By way of example, table 2 shows an example of the storage paths of some shared libraries in a hong-and-Monte system provided by an embodiment of the present application.

TABLE 2

……/${LIB}/…/ability
	……/${LIB}/…/accessibility

As shown in Table 2, the shared library of ability, accessibility in the hong Monte System may all be stored under the { LIB } path.

An application namespace is a namespace that is used for the framework (e.g., including but not limited to ArkUI frameworks, etc.) side in a hong system, such as: the ArkUI framework creates an ACE namespace, etc., for Network APIs (NAPI). The application namespaces may be used for the application to load shared libraries within the application, and if there is no application namespace, the application cannot load shared libraries within the application.

In some scenarios, the application namespace will have the same shared library (libc++ so) as the system namespace (e.g., default namespace, AOSP namespaces, etc.). Thus, to avoid conflicts between these shared libraries, in some embodiments, the application namespaces, default namespaces, AOSP namespaces, etc. are isolated from each other, i.e., the shared libraries from each other are not visible.

In some embodiments, loading of the shared library may also be achieved by configuring the shared library included in the application namespace with a whitelist, i.e. only shared libraries located in the whitelist may be directly loaded by the application.

Table 3 shows an example of some shared libraries in a white list provided by an embodiment of the present application.

TABLE 3 Table 3

libc.so
	libdl.so
libm.so
	libz.so
libEGL.so
	libGLESv3.so
libOpenSLES.so

As shown in table 3, the shared libraries of libc.so, libdl.so, libm.so, libz.so, etc. may all be located in the whitelist.

By way of example, FIG. 17 illustrates a schematic diagram of a process for a graphics implementation provided by an embodiment of the present application. As shown in fig. 17, the process includes: an application in a hong-and-Monte system may create or apply for a surface when there is a graphical display need for the application, i.e., when the application is to display several data. Wherein surface corresponds to a data buffer that can be used by an application to draw data therein. In some examples, the hong system may itself create a surface (this is exemplified in FIG. 17). In other examples, the hong system may apply for surface to the android system, which may apply for surface to the WMS of the android system through a gateway service such as that shown in fig. 10. The application does not limit the way the surface is acquired by the hong Monte-Pod system.

In some examples, because the window service in the hong system is tailored, the hong system may apply for creating windows to the android system, such as by applying for creating windows to WMSs included in the android system through a gateway service such as that shown in fig. 10, and the like. Accordingly, the android system may invoke the WMS to create a window for it. Wherein the window may be used to determine information such as the size, location, etc. of the drawn graphic and to create a corresponding surface view (SurfaceView) for the window. It is understood that the window may be used to carry SurfaceView and SurfaceView to carry surface. The android system may then notify the hong system of the created window handle so that the hong system knows the display location of the surface. It will be appreciated that the window handle may be an address index of the window, through which the location of the window may be found.

In some examples, the hong-and-Monte System may apply for creating a window from the android system, and after acquiring the window handle, perform a subsequent operation, i.e., perform an operation of rendering data into the created surface. The application does not limit the opportunity of the hong system to apply for creating the window to the android system.

Furthermore, the HongMonte System can complete the initialization of the EGL by loading the driver library file in the android system through the EGL, such as libEGL. Where EGL is the interface between a rendering API (e.g., openGL ES) and a native window system (e.g., surfaceView, etc.). Its main purpose is to prepare the rendering environment for OpenGLES. And then, loading a driver library file in the android system, such as libGLES.so, through OpenGLES to complete surface rendering. Such as: the hong system may render through OpenGLES using the capabilities of the android system's GPU.

Finally, the surface may be passed to the surface composition (surfaceflinger) service to perform composition operations by invoking the SwapBuffers interface through eglSwapBuffers operations. Further, the surface composition service may perform hardware composition operations to hwcompoer, such as providing a composed surface, by hwcompoer to pass the composed graphic to a display screen for display.

It will be appreciated that both EGL and OpenGLES can load corresponding driver libraries in the android system in a manner such as that described in FIG. 15A or FIG. 15B to avoid the problem of ABI incompatibility.

Fig. 18 shows a flowchart of a method for implementing graphics according to an embodiment of the present application, where the method includes the following steps:

s1901, applying for surface (surface).

In some embodiments, applications of the android system or encapsulated applications may apply for surface to the WMS through shell activity (SHELLACTIVITY). Accordingly, after receiving the application message, the WMS may apply for a surface to the surface composition (surfaceflinger) service. The surface composition service may return the created surface to the application of the android system through the WMS.

The surface composition service is a graphics server in the android system, and in some embodiments, may be used to provide surface and complete composition and rendering of surfaces drawn (or rendered) in a semi-container.

S1902, startup capability (ability).

And starting ability in the hong Monte system by the application in the android system, and transmitting the applied surface to the hong Monte system through gateway service. Accordingly, the hong system enables the operation of initiating ability via the ability module.

S1903, creating an ACE interface environment.

Among these, the hong system can create an ACE interface environment, such as AceView, in ability through an ACE module. Creation of an ACE interface environment may be accomplished, for example, by CREATEACEVIEW functions.

S1904, creating a platform window.

The creation of the platform window may be accomplished, for example, by SetPlatormWindow functions.

S1905, acquiring a display area of the EGL.

Such as Flutter shells (Shell), can be used to achieve the acquisition of the EGL display area by EGLGETDISPLAY function.

In some embodiments, flutter Shell is used to complete Flutter docking to various platforms such as android, hong Meng, windows, etc., mainly complete EGL environment initialization, dock local window system, and provide display and hardware acceleration capability support for graphics front end.

S1906, initializing the EGL environment.

Initialization of the EGL environment may be accomplished through eglCreateWindowSurface functions as Flutter Shell.

S1907, creating a window of the local EGL.

The creation of a window of the local EGL may be accomplished through eglCreateWindowSurface functions as Flutter Shell.

S1908, creating an EGL context.

Such as by Flutter Shell creating the context of the current EGL, i.e., creating the context of the running environment.

S1909, acquiring exchange data of the EGL.

It is understood that steps S1904 to S1909 are operations of initializing the environment of the EGL. In this process, to avoid the problem of ABI incompatibility, the EGL may call a driver library in the android system outside the semi-container, such as by using a libhybris scheme such as that shown in fig. 15A (this is illustrated in fig. 18). Of course, the driver libraries in the android system may also be called by an android library adaptation scheme such as that described in fig. 15B, which is not limited by the present application.

S1910, transmitting exchange data to the surface synthesis service.

When the initialization of the running environment is completed, the exchange data in the surface, that is, the exchange cache (swapBuffer) can be transmitted back to the surface created in the android system before.

In some embodiments, in step S1901 shown in fig. 18, the applied surface may be distributed by a graphics allocation (gralloc) module in the android system. By way of example, FIG. 19 illustrates a process diagram of another graphical implementation provided by an embodiment of the present application. As shown in fig. 19, the gralloc module may pass surface to SHELLACTIVITY of the android application through a surface composition service in the android system. Accordingly, the android system passes the surface to the hong Monte System through the gateway service, such as ability in the Window API. The hong and Monte Care system uses the surface as a rendering cache for the graphics module, which may perform steps S1906 through S1909, etc., as shown in FIG. 18, to render data into the rendering cache, i.e., the surface. After the drawing is completed, the drawing can be transmitted to an android system through swapBuffer of the EGL to execute the operation of synthesizing and transmitting display.

Fig. 20 is a schematic process diagram of an ACE-based graphics implementation method according to an embodiment of the present application. For example, as shown in fig. 20, when there is a need for displaying graphics in an application in the hong-and-Monte system, the resource manager (ResourceManager) is initialized through step 1, where after the resource management is initialized, the subsequent operations of applying for surface, creating a rendering environment, and the like can be performed. An ACE container (container) is then created by step 2, where the process of creating an ACE container, i.e. the process of creating an ACE interface environment, creating an EGL context, etc. such as described in fig. 18.

Surface is applied to hybris via step 3.1. Accordingly, hybiris may service the application surface to the surface composition (surfaceflinger) in the android system through step 3.2 after receiving the request for the application surface. Wherein hybiris, i.e., libhybris module, which is an ABI-compatible library, may be used to support calling a driver library outside a semi-container and a device driver, such as surfaceflinger, etc., inside the semi-container.

Accordingly, in the hong Monte System, after receiving the surface allocated from surfaceflinger, the initialization of the EGL can be completed by step 4. The operations of drawing the surface are then performed by initializing (JavaScript, js) engines at step 5 and by step 6, the Js engines being operable to complete the drawing of the surface in JavaScript language. After the drawing is completed, operations eglSwapBuffers are performed by step 7, and call swapBuffers passes the drawn surface to surfaceflinger. Accordingly, after surfaceflinger receives the surface of the drawing completion, the operations of compositing and displaying may be performed through step 8.

In some embodiments, the VSYNC signal for triggering the graphics drawing process may be generated by hwcomposer in the android system, passed through the gateway service into the ArkUI framework in the hong system. Accordingly, the application process in the hong system can execute the graphic drawing operation after receiving the VSYNC signal.

In some examples, as shown in fig. 21, the VSYNC signal generated by hwcomposer in the android system may be passed to the ArkUI framework in the hong system through the surface composition (surfaceflinger) service included in the AOSP service.

In other examples, the VSYNC signal generated by hwcomposer in the android system may be passed to SHELLACTIVITY in the android system and then passed to the ArkUI framework in the hong system through the gateway service.

The following describes the graphics flow in an embodiment of the present application by way of example only.

Scene one, the scene of shooing. As shown in fig. 22, the flow related to graphics in this scenario mainly includes:

1. creating a surface.

When creating a consumer (consumer) in the hong-and-Monte system, at the adapter layer, an android producer (producer) corresponding to the hong-and-Monte system, i.e., a producer in the android system, and an android consumer, i.e., a consumer in the android system, are created. And binding the android producer with the surface ID of the hong Mongolian system, and transmitting the android producer into a window gateway service included in the gateway service.

Alternatively, the adapter may be located in the gateway service or may exist independently.

In the photo and video scene, the description of the producer and the consumer can refer to the description in the related art.

2. Parameters are set.

When default parameters of surface are set in the hong Monte-Meng system, corresponding parameters are set for android consumers at the adapter layer correspondingly.

3. Registering and monitoring.

When surface monitoring is set in the hong Monte-Meng system, a callback function (callback) is converted into a function pointer, the function pointer is transmitted into an adapter layer, and the function pointer is packaged into a consumer monitor (ConsumerListener) in the adapter layer and is set in an android consumer. It will be appreciated that the purpose of the listening is for the consumer to determine when to present an image.

4. Camera applications.

In the application process, after parameters are set and monitored, the surface of the hong system is transmitted into a camera frame (CAMERAFWK) of the hong system, and the camera frame transmits the surface of the hong system into a camera gateway service (CAMERA GATEWAY SERVICE) included in the gateway service. The camera gateway service obtains the android surface existing in the window gateway service through the surface ID of the hong Monte System, and the android surface is transmitted into the original flow of the hong Monte System, namely, the hong Monte System camera service, and is used as the filling data of the production end.

5. A callback is received.

When the production end registers a cache (DequeueBuffer) in a cache queue (BufferQueue) through an android producer, at the adapter layer, a monitoring callback is received, a hong Mongolian application is notified through a function pointer, and a monitoring callback function at the hong Mongolian system side is executed. It will be appreciated that the cache may be retrieved from BufferQueue by operations DequeueBuffer to fill the retrieved cache with data. The filled cache may be placed back to BufferQueue by the operation of dequeue cache (QueueBuffer).

6. The cache (AcquireBuffer) is obtained.

After receiving the monitor callback, the hong system side calls AcquireBuffer function acquisition buffer (buffer) of the hong consumer, at this time, at the adapter layer, the graphics buffer (GraphicBuffer) at the android side is acquired through AcquireBuffer of the consumer, and the data parameters in GraphicBuffer are transferred to the hong application and returned to the application.

7. The cache (ReleaseBuffer) is released.

When the buffer is released, the HongMong System side calls the ReleaseBuffer function of the HongMong Consumer to release the buffer, the data parameters in the surface are transferred to the adapter layer and converted into GraphicBuffer, and then GraphicBuffer of the android System side is released through the ReleaseBuffer of the android Consumer.

Scene two, video scene. As shown in fig. 23, the flow related to the image in the scene mainly includes:

1. Media creation surface.

Creating a hong surface in a media gateway service included in the gateway service, binding the android surface held by the media with a corresponding hong surface ID, and transmitting the binding to a window gateway service included in the gateway service.

2. And the camera acquires the surface of the android system side.

The media transmits the hong surface to a hong camera frame, the camera frame transmits the hong surface to a camera gateway service, the camera gateway service acquires the android surface in the window gateway service through the hong surface ID, and the android surface is transmitted to a hong system native process, namely the hong system camera service.

In some embodiments, in the above scenario, interfaces bridging to the android system, such as AcquireBuffer, releaseBuffer, create surface interfaces, and related setup (set) and get interfaces, may be added in the adapter layer, or gateway service, to provide the ability to create and operate surface on the android system side.

In some embodiments, in the above scenario, related implementations of the hong surface may be added to the gateway service, providing the ability to create the hong surface in the gateway service.

In some embodiments, in the above scenario, an interface may be added in the gateway service, or in a window gateway service included in the gateway service, to manage mapping between the surface ID of the hong system and the surface of the android system, and provide the ability to obtain the surface of the android system according to the surface ID of the hong system.

Fig. 24 is a schematic flow chart of a window implementation method under multiple systems according to an embodiment of the present application, where the method is applied to an electronic device. As shown in fig. 24, the method includes the steps of:

s2401, in response to the first user operation, the first operating system sends a first request to the gateway service. Accordingly, the gateway service receives a first request from the first operating system.

Wherein the first request is for implementing a target function.

In some embodiments, the first user operation includes a user operation on a first application, where the first application may run in a first operating system or may run in a second operating system.

S2402, the gateway service sends a first request to the second operating system. Accordingly, the second operating system receives the first request from the gateway service.

The first operating system and the second operating system are both installed in the electronic equipment, the first operating system operates in the semi-container, and the second operating system operates outside the semi-container.

S2403, responding to the first request, and enabling the second operating system to realize the target function through the target service in the second operating system.

The first operating system does not include the target service, that is, the semi-container does not include the target service.

In some embodiments, the target function may comprise a window function and the target service may comprise a window management service WMS. Of course, in other embodiments, the target function may also include other functions, such as: the present application does not specifically limit the target functions, and the target service may also include other services, such as: application management services, etc., the present application is not particularly limited to the target service either.

By way of example, the window functions may include one or more of the following: acquiring window attributes, adjusting window sizes, acquiring window focuses, managing window life cycles, and acquiring or setting window modes; the window attribute comprises one or more of window size, window name and window identification, and the management window life cycle comprises: one or more of creating a window, displaying a window, hiding a window, destroying a window.

In some embodiments, the method shown in fig. 24 may further comprise the following steps (none of which are shown in the figures):

s2404, responding to a second user operation, and loading the first library file by the first operating system.

The first library file corresponds to the second library file of the first operating system, or is described as that the first library file has a corresponding relationship with the second library file of the first operating system. The first library file is a library file corresponding to the second operating system, the first library file is compatible with the second operating system, and the second library file is incompatible with the second operating system.

The first library file and the second library file may be, for example, a graphics driver library as described above, but of course, the library files may be other types of library files, which the present application is not limited to.

In some embodiments, the first library file may be preset in the first operating system. The ABI compatibility scheme described with reference to fig. 15A may be used with respect to a specific implementation of this embodiment.

In other embodiments, the loading of the first library file by the first operating system may be embodied as: the first operating system relocates to the first library file through the linker during loading of the second library file. The ABI compatibility scheme described with reference to fig. 15B may be used with respect to a specific implementation of this embodiment.

Taking the graphics driver library as an example, in some embodiments, the first library file may include libegl.so and libgles.so, and the first operating system loads the first library file, that is, loads libegl.so and libgles.so. In this embodiment, step S2404 may be embodied as step S2405.

S2405, loading libEGL.so through the EGL in the first operating system and loading libGLES.so through OpenGLES in the first operating system, and completing the rendering operation of the graph.

In some embodiments, step S2406 may also be included prior to step S2405.

S2406, responding to a second user operation, and acquiring a surface by the first operating system.

The surface is used for bearing graphic data of a second application, and the second application is operated in the first operating system.

In some embodiments, the first operating system may create a surface.

In other embodiments, the first operating system may apply for a surface from the second operating system, i.e., the surface is created by the second operating system. The first operating system sends a second request to the gateway service, the second request requesting creation of a surface. Accordingly, the second operating system receives the second request from the gateway service, creates a surface in response to the second request, and sends the surface to the gateway service. Accordingly, the first operating system receives a surface from the gateway service.

In some embodiments, prior to step S2404, or prior to step S2406, the second operating system may generate a VSYNC signal and send the VSYNC signal to the first operating system. Accordingly, after receiving the VSYNC signal, the first operating system executes step S2404.

In some embodiments, after step S2405, the first operating system may send the rendered surface to the second operating system. Accordingly, after receiving the rendered surface, the second operating system may perform operations of synthesizing and displaying the surface.

In some embodiments, the method shown in fig. 24 may further comprise the following steps (not shown in the figures):

s2407, responding to the operation of the third user, and receiving the input event sent by the second operating system from the input channel by the first operating system.

Wherein the input channel is established by the second operating system. Reference is made to the specific description above for an implementation of this step.

The foregoing description of the solution provided by the embodiments of the present application has been mainly presented in terms of a method. It will be appreciated that the electronic device, in order to achieve the above-described functions, includes corresponding hardware structures and/or software modules that perform the respective functions. The various illustrative units and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or a combination of hardware and computer software. Whether a function is implemented as hardware or computer-driven hardware depends upon the particular application and design constraints imposed on the solution. Those skilled in the art may implement the described functionality using different approaches for each particular application, but such implementation is not to be considered as beyond the scope of the embodiments of the present application.

The embodiment of the application can divide the functional modules of the electronic device according to the method example, for example, each functional module can be divided corresponding to each function, or two or more functions can be integrated in one processing unit. The integrated units may be implemented in hardware or in software functional modules. It should be noted that, in the embodiment of the present application, the division of the units is schematic, which is merely a logic function division, and other division manners may be implemented in actual practice.

As shown in fig. 25, a schematic structural diagram of an electronic device according to an embodiment of the present application is provided, and an electronic device 2500 may be used to implement the method executed by the electronic device described in each of the above method embodiments. By way of example, the electronic device 2500 may specifically include: a processing unit 2501.

Wherein the processing unit 2501 is configured to support the electronic device 2500 to perform all the steps of fig. 18. And/or the processing unit 2501 is configured to support the electronic device 2500 in performing all the steps of fig. 24. And/or the processing unit 2501 is also configured to support the electronic device 2500 in performing other steps performed by the electronic device in embodiments of the present application.

Optionally, the electronic device 2500 shown in fig. 25 may further include a communication unit 2502, where the communication unit 2502 is configured to support the electronic device 2500 to perform a step of communication between the electronic device and other devices in an embodiment of the present application.

Optionally, the electronic device 2500 shown in fig. 25 may further include a display unit 2503, where the display unit 2503 is used to support the electronic device 2500 to perform various display operations.

Optionally, the electronic device 2500 shown in fig. 25 may further include a storage unit (not shown in fig. 25) in which a program or instructions are stored. The processing unit 2501, when executing the program or instructions, enables the electronic device 2500 illustrated in fig. 25 to perform the methods illustrated in the method embodiments described above.

The technical effects of the electronic device 2500 shown in fig. 25 may refer to the technical effects of the method shown in fig. 24 and the like, and will not be described herein. The processing unit 2501, which is referred to in the electronic device 2500 illustrated in fig. 25, may be implemented by a processor or a processor-related circuit component, and may be a processor or a processing module. The communication unit 2502 may be implemented by a transceiver or transceiver-related circuit component, which may be a transceiver or transceiver module. The display unit 2503 may be implemented by a display related component.

The embodiment of the present application also provides a chip system, as shown in fig. 26, which includes at least one processor 2601 and at least one interface circuit 2602. The processor 2601 and the interface circuit 2602 may be interconnected by wires. For example, interface circuit 2602 may be used to receive signals from other devices. For another example, interface circuit 2602 may be used to send signals to other devices (e.g., processor 2601). Illustratively, the interface circuit 2602 may read instructions stored in the memory and send the instructions to the processor 2601. The instructions, when executed by the processor 2601, may cause the electronic device to perform the various steps performed by the electronic device in the embodiments described above. Of course, the system-on-chip may also include other discrete devices, which are not particularly limited in accordance with embodiments of the present application.

Alternatively, the processor in the system-on-chip may be one or more. The processor may be implemented in hardware or in software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, or the like. When implemented in software, the processor may be a general purpose processor, implemented by reading software code stored in a memory.

Alternatively, the memory in the system-on-chip may be one or more. The memory may be integral with the processor or separate from the processor, and the application is not limited. The memory may be a non-transitory processor, such as a ROM, which may be integrated on the same chip as the processor, or may be separately provided on different chips, and the type of memory and the manner of providing the memory and the processor are not particularly limited in the present application.

The chip system may be a field programmable gate array (field programmable GATE ARRAY, FPGA), an Application Specific Integrated Chip (ASIC), a system on chip (SoC), a central processing unit (central processor unit, CPU), a network processor (network processor, NP), a digital signal processing circuit (DIGITAL SIGNAL processor, DSP), a microcontroller (micro controller unit, MCU), a programmable controller (programmable logic device, PLD) or other integrated chip, for example.

It should be understood that the steps in the above-described method embodiments may be accomplished by integrated logic circuitry in hardware in a processor or instructions in the form of software. The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in a hardware processor for execution, or in a combination of hardware and software modules in the processor for execution.

The embodiment of the application also provides a computer storage medium, wherein computer instructions are stored in the computer storage medium, and when the computer instructions are run on the electronic equipment, the electronic equipment is caused to execute the method described in the embodiment of the method.

An embodiment of the present application provides a computer program product comprising: computer program or instructions which, when run on a computer, cause the computer to perform the method described in the method embodiments described above.

In addition, the embodiment of the application also provides a device, which can be a chip, a component or a module, and can comprise a processor and a memory which are connected; the memory is configured to store computer-executable instructions, and when the apparatus is running, the processor may execute the computer-executable instructions stored in the memory, so that the apparatus performs the methods in the method embodiments described above.

The electronic device, the computer storage medium, the computer program product, or the chip provided in this embodiment are used to execute the corresponding methods provided above, so that the beneficial effects thereof can be referred to the beneficial effects in the corresponding methods provided above, and will not be described herein.

It will be appreciated by those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. The embodiments may be combined or referenced to each other without conflict. The above-described apparatus embodiments are merely illustrative, e.g., the division of modules or units is merely a logical functional division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and the parts shown as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a device (may be a single-chip microcomputer, a chip or the like) or a processor (processor) to perform all or part of the steps of the methods of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the application is subject to the protection scope of the claims.

Claims

1. A method for implementing a window in a multi-system, the method being applied to an electronic device, the method comprising:

responding to a first user operation, and sending a first request to a gateway service by a first operating system, wherein the first request is used for realizing a target function;

a second operating system receives the first request from the gateway service;

responding to the first request, and realizing the target function through a target service in the second operating system;

The first operating system and the second operating system are both installed in the electronic equipment, the first operating system operates in the semi-container, the second operating system operates outside the semi-container, and the first operating system does not comprise the target service.

2. The method of claim 1, wherein the first user operation comprises a user operation on a first application running in the first operating system or the first application running in the second operating system.

3. The method according to claim 1 or 2, wherein the target function comprises a window function and the target service comprises a window management service WMS.

4. A method according to claim 3, wherein the window function comprises one or more of: acquiring window attributes, adjusting window sizes, acquiring window focuses, managing window life cycles, and acquiring or setting window modes; the window attribute includes one or more of window size, window name, window identification, and the management window lifecycle includes: one or more of creating a window, displaying a window, hiding a window, destroying a window.

5. The method according to any one of claims 1-4, further comprising:

Responding to a second user operation, loading a first library file by the first operating system, wherein the first library file corresponds to a second library file of the first operating system, the first library file is a library file corresponding to the second operating system, the first library file is compatible with the second operating system, and the second library file is incompatible with the second operating system.

6. The method of claim 5, wherein the first library file is pre-located in the first operating system.

7. The method of claim 5, wherein the first operating system loading a first library file comprises:

And in the process of loading the second library file by the first operating system, repositioning the first library file through a linker.

8. The method of any one of claims 5-7, wherein the first library file comprises libegl.so and libgles.so;

The first operating system loads libegl.so and libgles.so, including:

And loading the libEGL.so through the EGL in the first operating system and loading the libGLES.so through OpenGLES in the first operating system to complete the rendering operation of the graph.

9. The method of claim 8, wherein prior to said loading said libegl.so by EGL in said first operating system and said libgles.so by OpenGLES in said first operating system, said method further comprises:

Responding to the second user operation, and creating a surface by the first operating system, wherein the surface is used for bearing graphic data of a second application; wherein the second application is running in the first operating system.

10. The method of claim 8, wherein prior to said loading said libegl.so by EGL in said first operating system and said libgles.so by OpenGLES in said first operating system, said method further comprises:

responding to the second user operation, the first operating system sends a second request to the gateway service, wherein the second request is used for requesting to create a surface;

The second operating system receiving the second request from the gateway service;

responding to the second request, the second operating system creates the surface and sends the surface to the gateway service;

The first operating system receives the surface from the gateway service.

11. The method according to any one of claims 8-10, wherein after the loading of the libegl.so by EGL in the first operating system and the loading of the libgles.so by OpenGLES in the first operating system, the method further comprises:

the first operating system sends a surface with the rendering completed to the second operating system;

and the second operating system executes the operations of surface synthesis and display sending of the rendered surface.

12. The method according to any one of claims 9-11, wherein before the loading of the libegl.so by EGL in the first operating system and the loading of the libgles.so by OpenGLES in the first operating system, the method further comprises:

the second operating system generates a vertical synchronization VSYNC signal;

the second operating system sends the VSYNC signal to the first operating system.

13. The method according to any one of claims 1-12, further comprising:

And responding to a third user operation, the first operating system receives an input event sent by the second operating system from an input channel, and the input channel is established by the second operating system.

14. An electronic device, comprising: a processor and a memory coupled to the processor, the memory for storing computer program code, the computer program code comprising computer instructions, the processor reading the computer instructions from the memory to cause the electronic device to perform the method of any of claims 1-13.

15. A computer readable storage medium, characterized in that the computer readable storage medium comprises a computer program which, when run on an electronic device, causes the electronic device to perform the method according to any one of claims 1-13.

16. A computer program product, characterized in that the computer program product, when run on a computer, causes the computer to perform the method according to any of claims 1-13.