CN117827476A

CN117827476A - Event processing method, event processing device, electronic equipment and readable storage medium

Info

Publication number: CN117827476A
Application number: CN202211203398.XA
Authority: CN
Inventors: 续小丁; 孙祺
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-09-29
Filing date: 2022-09-29
Publication date: 2024-04-05

Abstract

The application relates to the technical field of event processing, and provides an event processing method, an event processing device, electronic equipment and a readable storage medium, wherein the event processing method comprises the following steps: when an event to be processed is acquired, judging whether a foreground focus window is an embedded window or not; when the foreground focus window is an embedded window, the event to be processed is called back to a parent window to which the embedded window belongs; and the host process corresponding to the father window processes the event to be processed, so that when the embedded window exists, the event to be processed is handed over to the host process corresponding to the father window to be processed, and interaction between the embedded window and the father window is realized.

Description

Event processing method, event processing device, electronic equipment and readable storage medium

Technical Field

The present disclosure relates to the field of event processing technologies, and in particular, to an event processing method, an event processing device, an electronic device, and a readable storage medium.

Background

The window system provides embedded window display and interaction capability, supports shortcut task cards, and is convenient for users to efficiently use shortcut tasks.

After the application is pulled up in the embedded window mode, the focus is transferred to the embedded window. The system key event is passed to the embedded window by default, so the key event will be consumed by the embedded window. Different key events in different scenarios will have different response results, which can be unexpected. An example scenario is as follows:

In the new stack and stack disassembly mode, the embedded Task root Activity triggers a Back event in a scene displayed in the foreground, and the Back event is consumed by the Android native process, and the service logic is as follows: destroying the Activity; finally, the embedded window is destroyed and the parent window is not destroyed, so that a display error is caused;

in the multiplexing main stack mode, the Back event is triggered in the scene displayed by the foreground by the embedded root Activity of the embedded Task, and the Back event is consumed by the foreground in the Android native process, and the service logic is as follows: destroying the Activity and displaying other activities under the Activity; eventually causing the embedded window display area to display an embedded window that is not pulled up by the user.

Disclosure of Invention

The application provides an event processing method, an event processing device, electronic equipment and a readable storage medium, and aims to avoid the situation that an event cannot interact with a parent window after being consumed by an embedded window.

In a first aspect, the present application provides an event processing method, including:

when an event to be processed is acquired, judging whether a foreground focus window is an embedded window or not;

when the foreground focus window is an embedded window, the event to be processed is called back to a parent window to which the embedded window belongs;

And processing the event to be processed by the host process corresponding to the parent window.

According to the event processing method, when the event to be processed is acquired, whether the foreground focus window is an embedded window is judged; when the foreground focus window is an embedded window, the event to be processed is called back to a parent window to which the embedded window belongs; and the host process corresponding to the father window processes the event to be processed, so that when the embedded window exists, the event to be processed is handed over to the host process corresponding to the father window to be processed, and interaction between the embedded window and the father window is realized.

In one possible implementation manner, the determining whether the foreground focal window is an embedded window includes:

extracting a zone bit in the foreground focus window parameter;

when the parameter value of the zone bit is a first parameter value, determining that the foreground focus window is an embedded window;

and when the parameter value of the zone bit is a second parameter value, determining that the foreground focus window is not an embedded window.

In a possible implementation manner, the extracting the flag bit in the foreground focal window parameter includes:

Extracting a Task global variable mIsLauncheldFromHnEmbeddWindow in the foreground focus window;

and taking the mIsLauncheldFromHnEmbeddWindow as a zone bit in the foreground focus window parameter.

In one possible implementation manner, before the determining whether the foreground focal window is the embedded window, the method further includes:

judging whether the foreground focus window is an Activity window or not;

and when the foreground focus window is an Activity window, executing the step of judging whether the foreground focus window is an embedded window.

In one possible implementation manner, the determining whether the foreground focal window is an Activity window includes:

judging whether a Window State global variable mActivityRecord in the foreground focus window is empty or not;

and when the Window State global variable mActivityRecord is not empty, determining that the focus window corresponding to the event to be processed is an Activity window.

In one possible implementation manner, the callback of the event to be processed to the parent window to which the embedded window belongs includes:

canceling a foreground processing tag in the event to be processed;

and callback the event to be processed of which the foreground processing tag is canceled to the parent window to which the embedded window belongs.

In one possible implementation manner, before the event to be processed is acquired, the method further includes:

foreground processing tags are added to events to be processed.

In one possible implementation manner, when the event to be processed is acquired, determining whether the foreground focal window is an embedded window includes:

forwarding the event to be processed to a PhoneWindowManager function;

judging whether the foreground focus window is an embedded window or not through a PhoneWindow manager function.

In one possible implementation manner, the forwarding the event to be processed to a PhoneWindowManager function includes:

calling a native InputManager function;

and forwarding the event to be processed to a PhoneWindowManager function through the native InputManager function.

In one possible implementation, the method further includes:

when the foreground focus window is not an Activity window or the foreground focus window is not an embedded window, judging whether the event to be processed contains a foreground processing tag or not;

distributing the event to be processed to the foreground focus window application when the event to be processed contains a foreground processing tag;

and discarding the event to be processed when the event to be processed does not contain the foreground processing tag.

In a second aspect, the present application provides an event processing apparatus, including:

the judging module is used for judging whether the foreground focus window is an embedded window or not when the event to be processed is acquired;

the callback module is used for callback the event to be processed to a parent window to which the embedded window belongs when the foreground focus window is the embedded window;

and the processing module is used for processing the event to be processed by the host process corresponding to the parent window.

In a third aspect, the present application provides an electronic device, including:

one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, the one or more computer programs comprising instructions that, when executed by the electronic device, cause the electronic device to perform the event processing method as described in the first aspect or any of the possible implementations of the first aspect.

In a fourth aspect, the present application provides a computer readable storage medium having stored therein a computer program which, when executed by a processor, causes the processor to perform the event processing method as described in the first aspect or any of the possible implementation manners of the first aspect.

In a fifth aspect, the present application provides a chip, the chip including a processor and a data interface, the processor reading instructions stored on a memory through the data interface, performing the event processing method of the first aspect or any one of the possible implementation manners of the first aspect.

Optionally, as a possible implementation manner, the chip may further include a memory, where the memory stores instructions, and the processor is configured to execute the instructions stored on the memory, where the instructions, when executed, are configured to perform the event processing method of the first aspect or any one of the possible implementation manners of the first aspect.

Drawings

FIG. 1 is a schematic scene diagram of prior art application process processing;

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

fig. 3 is a software structural block diagram of an electronic device according to an embodiment of the present application;

FIG. 4 is a flow chart of an event processing method according to an embodiment of the present disclosure;

FIG. 5 is a schematic view of a scenario for starting an embedded window of an event processing method according to another embodiment of the present application;

FIG. 6 is a schematic diagram of a display interface of an embedded window of an event processing method according to another embodiment of the present disclosure;

FIG. 7 is a block diagram illustrating embedded window initiation of an event handling method according to another embodiment of the present application;

FIG. 8 is a flowchart illustrating an event processing method according to another embodiment of the present disclosure;

FIG. 9 is a schematic overall flow chart of an event processing method according to another embodiment of the present disclosure;

fig. 10 is a schematic diagram of an embedded window judgment flow of an event processing method according to another embodiment of the present application;

FIG. 11 is a block diagram illustrating an event processing method according to another embodiment of the present application;

FIG. 12 is a flowchart illustrating an event processing method according to another embodiment of the present disclosure;

fig. 13 is a schematic structural diagram of an event processing device provided in the present application.

Detailed Description

The terms first, second, third and the like in the description and in the claims and drawings are used for distinguishing between different objects and not for limiting the specified sequence.

In the embodiments of the present application, words such as "exemplary" or "such as" are used to mean serving as examples, illustrations, or descriptions. Any embodiment or design described herein as "exemplary" or "for example" should not 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.

For clarity and brevity of description of the following embodiments, a brief description of an implementation scheme of event processing is first given:

at present, the window system provides embedded window display and interaction capability, supports a shortcut task card, and is convenient for a user to efficiently use the shortcut task. After the application is pulled up in the embedded window mode, the focus is transferred to the embedded window. The system key event is passed to the embedded window by default, so the key event will be consumed by the embedded window. Different key events in different scenarios will have different response results, which can be unexpected. An example scenario is as follows: in the new stack and stack disassembly mode, the embedded Task root Activity triggers a Back event in a scene displayed in the foreground, and the Back event is consumed by the Android native process, and the service logic is as follows: destroying the Activity; finally, the embedded window is destroyed and the parent window is not destroyed, so that a display error is caused; in the multiplexing main stack mode, the Back event is triggered in the scene displayed by the foreground by the embedded root Activity of the embedded Task, and the Back event is consumed by the foreground in the Android native process, and the service logic is as follows: destroying the Activity and displaying other activities under the Activity; eventually causing the embedded window display area to display an embedded window that is not user-pulled, returning to the embedded window to the WeChat chat interface as shown in FIG. 1.

Based on the problems in the technical scheme, the application provides an event processing method, which judges whether a foreground focus window is an embedded window or not when an event to be processed is acquired; when the foreground focus window is an embedded window, the event to be processed is called back to a parent window to which the embedded window belongs; and the host process corresponding to the father window processes the event to be processed, so that when the embedded window exists, the event to be processed is handed over to the host process corresponding to the father window to be processed, and interaction between the embedded window and the father window is realized. The event processing method can be applied to electronic devices such as mobile phones, tablet computers, desktop computers, laptops, notebook computers, ultra-mobile personal computers (UMPC), handheld computers, netbooks, personal digital assistants (Personal Digital Assistant, PDA), wearable electronic devices, smart watches and the like. The structure of the electronic device to which the event processing method is applied may be as shown in fig. 2.

As shown in fig. 2, fig. 2 is a diagram showing an example of the composition of an electronic device provided in the present application, the electronic device 200 may include a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (universal serial bus, USB) interface 230, a charge management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, an earphone interface 270D, a sensor module 280, keys 290, a motor 291, an indicator 292, a camera 293, a display 294, a subscriber identity module (subscriber identification module, SIM) card interface 295, and the like. The sensor module 280 may include a pressure sensor 280A, a gyroscope sensor 280B, a barometric sensor 280C, a magnetic sensor 280D, an acceleration sensor 280E, a distance sensor 280F, a proximity sensor 280G, a fingerprint sensor 280H, a temperature sensor 280J, a touch sensor 280K, an ambient light sensor 280L, a bone conduction sensor 280M, and the like.

It is to be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 200. In other embodiments, the electronic device 200 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.

Processor 210 may include one or more processing units such as, for example: the processor 210 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 (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and a command center of the electronic device 200, among others. 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 210 for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. The memory may hold instructions or data that the processor 210 has just used or recycled. If the processor 210 needs to reuse the instruction or data, it may be called directly from the memory. Repeated accesses are avoided and the latency of the processor 210 is reduced, thereby improving the efficiency of the system.

In some embodiments, processor 210 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.

It should be understood that the connection relationship between the modules illustrated in this embodiment is only illustrative, and does not limit the structure of the electronic device 200. In other embodiments of the present application, the electronic device 200 may also use different interfacing manners, or a combination of multiple interfacing manners, as in the above embodiments.

The wireless communication function of the electronic device 200 can be implemented by the antenna 1, the antenna 2, the mobile communication module 250, the wireless communication module 260, a modem processor, a baseband processor, and the like.

The wireless communication module 260 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 wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as applied on the electronic device 200. The wireless communication module 260 may be one or more devices that integrate at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 210. The wireless communication module 260 may also receive a signal to be transmitted from the processor 210, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

In some embodiments, antenna 1 and mobile communication module 250 of electronic device 200 are coupled, and antenna 2 and wireless communication module 260 are coupled, such that electronic device 200 may communicate with a network and other devices via wireless communication techniques. The wireless communication techniques may include the Global System for Mobile communications (global system for mobile communications, GSM), general packet radio service (general packet radio service, GPRS), code division multiple access (code division multiple access, CDMA), wideband code division multiple access (wideband code division multiple access, WCDMA), time division code division multiple access (time-division code division multiple access, TD-SCDMA), long term evolution (long term evolution, LTE), BT, GNSS, WLAN, NFC, FM, and/or IR techniques, among others. The GNSS may include a global satellite positioning system (global positioning system, GPS), a global navigation satellite system (global navigation satellite system, GLONASS), a beidou satellite navigation system (beidou navigation satellite system, BDS), a quasi zenith satellite system (quasi-zenith satellite system, QZSS) and/or a satellite based augmentation system (satellite based augmentation systems, SBAS).

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

A series of graphical user interfaces (graphical user interface, GUIs), which are all home screens of the electronic device 200, may be displayed on the display 294 of the electronic device 200. In general, the size of the display 294 of the electronic device 200 is fixed and only limited controls can be displayed in the display 294 of the electronic device 200. A control is a GUI element that is a software component contained within an application program that controls all data processed by the application program and interactive operations on that data, and a user can interact with the control by direct manipulation (direct manipulation) to read or edit information about the application program. In general, controls may include visual interface elements such as icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, widgets, and the like. For example, in the embodiment of the present application, the display 291 may display virtual keys (one-key arrangement, start arrangement, scene arrangement).

The electronic device 200 may implement a photographing function through an ISP, a camera 293, a video codec, a GPU, a display 294, an application processor, and the like.

The electronic device 200 may implement audio functions through an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, an ear-headphone interface 270D, an application processor, and the like. Such as music playing, recording, etc.

In addition, an operating system is run on the components. Such as the hong Monte System, the iOS operating system, the Android open source operating system, the Windows operating system, and the like. An operating application may be installed on the operating system.

Fig. 3 is a software structural block diagram of an electronic device according to an 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. In some embodiments of the present application, the software architecture of the electronic device includes at least three layers, from top to bottom, an application layer, an application framework layer, and a hardware abstraction layer.

The application layer may include a series of application packages. The application packages may include applications such as cameras, gallery, calendar, call, map, navigation, WLAN, bluetooth, music, video, short message, etc., and in some embodiments of the present application, the application layer further includes an embedded window service, an embedded window module, and an embedded window interface module, where the embedded window service is a new module of the SystemUI module, and the embedded window module is a new module of the WM-Shell Lib module.

The embedded window module is used for realizing the main functions of embedded window display interaction, including start-up and exit control, window display control, state synchronization and event transmission.

The embedded window interface module is used for realizing the encapsulation of the embedded window capability interface and providing the encapsulation for the host process for calling.

The application layer in some embodiments of the present application also includes an hnededdview module.

The application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs of the application layer. The application framework layer includes a number of predefined functions. As shown in FIG. 3, the application framework layer 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 may acquire the size of the display screen, determine whether there is a status bar, lock a screen, intercept a screen, and the like, and in some embodiments of the present application, the application framework layer further includes an adjusted AMS module, an adjusted WMS module, a newly added embedded window interface set, a native input manager module, and a phonewindow manager module, where the phonewindow manager module includes a window state module, an actigitztagman international module, the window state module includes an hnb eddwindow method, an actigitztagmanageinternational module includes a takekeyeventbyhdwindow method, an hn egedwindedview module includes an onkeyenttask method, and the native input manager module includes an input displayer module, and the window module includes a keybeuebefore handleInterceptAction, inputDispatcher th method, and the actigitztagerw module includes a keyeventb method.

The adjusted AMS module is used for realizing embedded Activity starting and life cycle management.

The adjusted WMS module is used for realizing embedded Task management, activity jump control in the Task, focus and visibility management of an embedded window scene, config update and compatibility management.

The embedded window interface set is for use by a system application.

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 for providing communication functions of the electronic device. 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 of the electronic device 200, which aims to abstract the hardware.

For easy understanding, the following embodiments of the present application will take the electronic device 200 having the structure shown in fig. 2 and fig. 3 as an example, and the event processing method provided in the embodiments of the present application will be specifically described with reference to the drawings and application scenarios.

Fig. 4 is a flow chart of an event processing method according to an embodiment of the present application.

As shown in fig. 4, the event processing method may include:

step S30: when the event to be processed is acquired, judging whether the foreground focus window is an embedded window.

Under the general condition, when a user currently uses high-frequency shortcut services such as one-sweep, payment codes and the like, the operation is complicated, for example, the user needs to unlock firstly, then open the application, then select the corresponding service and the like; in the processes of screen-extinguishing, screen-locking and application use, for example, on-line conferences, videos and the like, shortcut services are used, operation is not uniform and inconvenient, the embodiment supports the shortcut task card to realize efficient shortcut task window display by providing the application window with embedded window display capability, namely, in the use process, the user can open the application through a preset operation, and the direct use calling mode shortcut service is realized, the window system provides embedded window display and interaction capability, supports the shortcut task card Launcher, and is convenient for the user to use shortcut tasks efficiently.

In order to open an application through an embedded window, as shown in a scene diagram of starting the embedded window in fig. 5, wherein (1) represents a main interface, and the embedded window displays a micro-letter pay-receive-pay application by operating a shortcut task card twice on the back, as shown in a display interface diagram of the embedded window in fig. 6, wherein 10 represents an embedded window of a loaded application, and 20 represents a parent window.

As shown in the module interaction diagram of embedded window starting shown in fig. 7, when the starting operation of the target application is detected, the host process service is triggered, the host process sends a request for establishing connection with the embedded window service to the embedded window service, the embedded window service sends a request for acquiring an embedded window cross-process communication instance to the embedded window module, the embedded window module returns the embedded window cross-process communication instance to the embedded window service, and the embedded window service returns the embedded window cross-process communication instance to the host process so as to realize direct communication between the host process and the embedded window module, wherein the host process can be a process corresponding to a father window.

After the communication connection between the host process and the embedded window module is established, the host process is initialized to finish the drawing of the parent window, and the specific drawing process is as follows: the host process sends a request for adding a parent window to the WMS, wherein the parent window request contains bitmap information, the window size of the parent window is sent to the Graphics drawing module for window drawing, the host process also sends layer information to the SurfaceFlinger for parent window layer synthesis, the parent window is displayed after the layer synthesis is completed, then the host process sends a request for starting an embedded window to the embedded window module, the request further comprises starting parameters, the starting parameters comprise a target window, a window size, a stack mode, a touch mode and a Back mode, the target window represents a window for starting a corresponding application, the window size represents the size of the embedded window, the stack mode comprises an application processing mode in the embedded window, the method comprises a new stack, a stack disassembly mode and a multiplexing main stack mode, the touch mode represents whether a control with touch interaction operation is needed in the embedded window, and the Back mode represents an application return processing mode in the embedded window.

The embedded window module configures a target window, a window mode, a window size, an embedded window mark bit and a stack mode of the embedded window according to the received starting parameters, wherein the window mode represents a display mode of the embedded window and comprises a multi-window display mode, a picture-in-picture display mode, a floating frame display mode and the like, the embedded window mark bit represents identification information of the embedded window, the embedded window module sends the target window, the window mode, the window size, the embedded window mark bit and the stack mode to the AMS module, the AMS module sends the window mode and the window size to an embedded application for pulling up the window according to the target window, then sends the embedded window mark bit and the stack mode to the WMS module, the embedded application sends the window size to the WMS module for window addition, the WMS module draws the window according to the window size and the window size, and the drawing process of the embedded window comprises the following steps of: the embedded application sends the window size to a Graphics drawing module, the Graphics drawing module notifies the WMS module after drawing is completed, the WMS module notifies the embedded window module that the stack control right is created after drawing is completed, the embedded window module transfers the stack control right to a host process, the host process performs Graphics layer combination to realize window display, and the host process performs Graphics layer combination specifically comprises: the host process hangs a stack layer under the SurfaceView, sends a configuration request for setting the visible layer of the embedded application stack to the SurfaceFlinger module, synthesizes the layers through the SurfaceFlinger module, and notifies the interaction module to display an interface after synthesis is completed, thereby completing the startup of the embedded window.

In this embodiment, because the embedded window is started, after the embedded window is displayed, the foreground focus is generally on the embedded window, when the acquired event to be processed is the event to be processed, the event to be processed is transmitted to the window corresponding to the foreground focus for processing, but when the event to be processed is consumed by the embedded window, in the new stack and stack disassembly modes, the Back event is triggered in the scene displayed by the foreground by the embedded Task root Activity, and under the Android native process, the Back event is consumed by the embedded window, and the service logic is: destroying the Activity; finally, the embedded window is destroyed and the parent window is not destroyed, so that a display error is caused; in the multiplexing main stack mode, the Back event is triggered in the scene displayed by the foreground by the embedded root Activity of the embedded Task, and the Back event is consumed by the foreground in the Android native process, and the service logic is as follows: destroying the Activity and displaying other activities under the Activity; and finally, the embedded window display area displays the embedded window which is not pulled up by the user, so that the event to be processed is handed over to the host process corresponding to the parent window for processing, and the interaction between the embedded window and the parent window is realized.

In a specific implementation, in order to realize interaction between the embedded window and the parent window, whether the foreground focus window is the embedded window is firstly judged, if the foreground focus window is not the embedded window, the problem cannot occur, and if the foreground focus window is the embedded window, the problem cannot occur, so that the system processing efficiency is improved.

Step S40: and when the foreground focus window is an embedded window, the event to be processed is called back to a parent window to which the embedded window belongs.

It should be noted that, in general, when the foreground focus window is an embedded window, the event to be processed is transferred to a window corresponding to the foreground focus for processing, however, in this embodiment, the event to be processed is recalled to a parent window to which the embedded window belongs, and the host process corresponding to the parent window processes the event to be processed, so that interaction between the embedded window and the parent window thereof is achieved.

Step S50: and processing the event to be processed by the host process corresponding to the parent window.

In the embodiment, when an event to be processed is acquired, judging whether a foreground focus window is an embedded window or not; when the foreground focus window is an embedded window, the event to be processed is called back to a parent window to which the embedded window belongs; and the host process corresponding to the father window processes the event to be processed, so that when the embedded window exists, the event to be processed is handed over to the host process corresponding to the father window to be processed, and interaction between the embedded window and the father window is realized.

Fig. 8 is a flowchart of an event processing method according to another embodiment of the present application, as shown in fig. 8, where the event processing method is based on the first embodiment, and the step S30 includes:

step S301, extracting a flag bit in the foreground focal window parameter.

In this embodiment, the foreground focus window parameter may be a Task global variable msislauncheldfrom hmideddwindows, where Task is a Task stack of the foreground focus window, and a flag bit for identifying the embedded window may also be obtained from other parameters.

Step S302, when the parameter value of the zone bit is a first parameter value, determining that the foreground focus window is an embedded window.

It should be noted that, the first parameter value may be true, or may be another parameter value, which is not limited in this embodiment, and when the parameter value of the flag bit is true, the foreground focus window is determined to be an embedded window.

Step S303, when the parameter value of the flag bit is the second parameter value, determining that the foreground focus window is not an embedded window.

It can be understood that the second parameter value may be false, or may be another type of parameter value, which is not limited in this embodiment, and when the parameter value of the flag bit is false, it is determined that the foreground focus window is not an embedded window.

As shown in the overall flow diagram of fig. 9, in the embedded window foreground display scenario, the system key event is transferred to the embedded window parent window instead of the embedded window itself, and the parent window decides how to consume the event. And when the native input manager.interactive keyBeforeQueuing distributes the key event to the PhonWindowmanager.interactive keyBeforeQueuing method, judging whether the foreground focus window is an embedded window. If yes, the callback interface informs the host process, sets a flag bit, cancels the action_pass_to_user flag, and prevents the event from being distributed TO the embedded window.

Step 2: when the embedded window is started, a flag bit is set in the Task, and the Task is identified as the embedded Task. If the focus window is an embedded window, executing step 2.1, then notifying a host process by a callback interface, and processing by the host process, if the focus window is not the embedded window, directly executing step 3, if the focus window is not the embedded window, transmitting a key event dispatch flow TO NativeInputManager.handleInterceptAction, nativeInputManager.handleInterceptAction by native inputManager.

In one possible implementation manner, the step S301 includes:

extracting a Task global variable mIsLauncheldFromHnEmbeddWindow in the foreground focus window; and taking the mIsLauncheldFromHnEmbeddWindow as a zone bit in the foreground focus window parameter.

In one possible implementation manner, before the step S30, the method further includes:

step S101, judging whether the foreground focus window is an Activity window.

In this embodiment, since there are multiple types of windows, for example, an Activity window or a View window, it is first determined whether the foreground focus window is an Activity window, and if the foreground focus window is not an Activity window, it is definitely not an embedded window, so before performing the embedded window determination, it is first determined whether the foreground focus window is an Activity window, thereby improving the efficiency of system processing.

Step S102, when the foreground focus window is an Activity window, step S30 is executed.

In a specific implementation, the process of identifying the focus window as an embedded window is as follows: judging whether the window is an Activity window or not, specifically judging whether a windowState global variable mActivityRecord is empty or not: windowState. MActivityRecord-! =null; whether the Task is an embedded Task or not is specifically determined whether the Task global variable mIsLauncheldFromHnEmbeddWindow is true or false; to sum up: if the window is Activity and the Task is the embedded window Task, the window is the embedded window;

As shown in the embedded window judging flow chart of fig. 10, firstly, judging whether the focus window is an Activity window, if the focus window is an Activity window, continuing to judge whether the Task is an embedded Task, if the Task is an embedded Task, returning true, if the focus window is not an Activity window, returning false, and if the Task is not an embedded Task, returning false to realize the judgment of the embedded window.

And when the global variable mActivityRecord is empty, returning a judging result to the PhonInputManager module, when the global variable mActivityManager is not empty, returning the judging result to the NatInputManager module, when the global variable mActivityManager is not empty, judging whether the front focus window is an embedded window, canceling the front focus processing label, notifying a host process to the ActivateTaskInternalmodule, notifying the host process of the HnEmbedScreen module again, and notifying the front focus window of the attached event by the ActivateTaskIntermodule, and judging whether the front focus window is the embedded window.

In one possible implementation manner, the step S101 includes:

judging whether the WindowState global variable mActivityRecord is empty or not; and when the Window State global variable mActivityRecord is not empty, determining that the focus window corresponding to the event to be processed is an Activity window.

In a specific implementation, in order to determine whether a foreground focus window is an Activity window, whether the focus window corresponding to the event to be processed is an Activity window is determined by whether a windowState global variable mActivityRecord is empty or not when the windowState global variable mActivityRecord is not empty, and whether the focus window corresponding to the event to be processed is not an Activity window is determined when the windowState global variable mActivityRecord is empty, so that accurate identification of the Activity window is realized.

Fig. 12 is a flowchart of an event processing method according to another embodiment of the present application, as shown in fig. 12, where the event processing method is based on the first embodiment, and the step S40 includes:

step S401, cancelling a foreground processing tag in the event to be processed.

In this embodiment, the foreground processing tag may be an action_pass_to_user flag, or may be a flag in another form, which is not limited in this embodiment, and in this embodiment, the action_pass_to_user flag is taken as an example TO describe, and when the foreground focus window is an embedded window, the callback interface notifies the host process, sets a flag bit flag, cancels the action_pass_to_user flag, and prevents the event from being dispatched TO the embedded window, so that the event is prevented from being dispatched TO the embedded window by using the foreground processing tag as the event processing tag.

And step S402, callback of the event to be processed of which the foreground processing tag is canceled to the parent window to which the embedded window belongs.

foreground processing tags are added to events to be processed.

In this embodiment, when an event to be processed is obtained, a foreground processing tag is added to the event to be processed, after whether the focus window is an embedded window is judged, the foreground processing tag is cancelled or reserved according to the judging result, and the event to be processed for which the foreground processing tag is cancelled is prevented from being dispatched to the embedded window, so that the processing of the event to be processed by the embedded window is avoided, and therefore, the processing window of the event to be processed can be determined through the foreground processing tag, and effective control of the event to be processed is realized.

In one possible implementation manner, the step S30 includes:

forwarding the event to be processed to a PhoneWindowManager module; and judging whether the foreground focus window is an embedded window or not through a PhoneWindow manager module.

In a specific implementation, in order to prevent the event to be processed from being directly dispatched to the embedded window for processing, after the event to be processed is acquired, the event to be processed is not directly dispatched to the embedded window but is dispatched to the PhoneWindowManager module, and the PhoneWindowManager module can be used for judging whether the foreground focus window is the embedded window, so that the event to be processed is prevented from being directly dispatched to the embedded window for processing.

In one possible implementation manner, the forwarding the event to be processed to a PhoneWindowManager module includes:

invoking a native InputManager module; and forwarding the event to be processed to a PhoneWindowManager module through the native InputManager module.

In this embodiment, in order to prevent the event to be processed from being directly dispatched to the embedded window for processing, the event to be processed is forwarded to the PhoneWindowManager module; judging whether the foreground focus window is an embedded window through a PhonWindowManager module, and judging whether the foreground focus window is the embedded window through the PhonWindowManager module in order to forward the event to be processed through establishing communication between the native InputManager module and the PhonWindowManager module, when the event to be processed is acquired, forwarding the event to be processed to the PhonWindowManager module through the native InputManager module, so that effective control of the event to be processed is realized.

In one possible implementation, the method further includes:

judging whether the event to be processed contains a foreground processing tag or not; distributing the event to be processed to the foreground focus window application when the event to be processed contains a foreground processing tag; and discarding the event to be processed when the event to be processed does not contain the foreground processing tag.

Continuing to refer to the overall flow chart shown in fig. 9, when the native inputmanager.internestkeybeforequeue distributes a key event to the phonewindowmanager.internestkeybeforequeue method, judging whether the foreground focus window is an embedded window. If yes, the callback interface informs the host process, if not, the processed result is returned TO the native input manager/internetworking method, the native input manager/internetworking method sends a key event dispatch flow TO NativeInputManager.handleInterceptAction, nativeInputManager.handleInterceptAction TO the input dispatcher/dispatcheonenlockded method, whether the Phone WindowManager return value contains action_PASS_TO_USER or not is judged, if yes, the processed result is distributed TO a foreground focus application, and if not, the action_PASS_TO_USER is discarded, so that effective control of the event TO be processed is achieved.

Fig. 13 shows a schematic structural diagram of an event processing device provided in the present application. The event processing apparatus 900 provided in the present application includes:

the judging module 901 is configured to judge whether a foreground focal window is an embedded window when an event to be processed is acquired;

A callback module 902, configured to callback the event to be processed to a parent window to which the embedded window belongs when the foreground focal window is the embedded window;

and the processing module 903 is configured to process the event to be processed by a host process corresponding to the parent window.

In the event processing method provided by the application, in the embodiment, when an event to be processed is acquired, whether a foreground focus window is an embedded window is judged; when the foreground focus window is an embedded window, the event to be processed is called back to a parent window to which the embedded window belongs; and the host process corresponding to the father window processes the event to be processed, so that when the embedded window exists, the event to be processed is handed over to the host process corresponding to the father window to be processed, and interaction between the embedded window and the father window is realized.

In a possible implementation manner, the determining module 901 is further configured to extract a flag bit in the foreground focal window parameter;

In a possible implementation manner, the determining module 901 is further configured to extract a Task global variable msisalanchedfromhombededwindow in the foreground focus window;

In a possible implementation manner, the determining module 901 is further configured to determine whether the foreground focal window is an Activity window;

In a possible implementation manner, the determining module 901 is further configured to determine whether a WindowState global variable mActivityRecord in the foreground focal window is empty;

In a possible implementation manner, the callback module 902 is further configured to cancel a foreground processing tag in the event to be processed;

In one possible implementation, the callback module 902 is further configured to add a foreground processing tag to the event to be processed.

In a possible implementation manner, the determining module 901 is further configured to forward the event to be processed to a PhoneWindowManager module;

and judging whether the foreground focus window is an embedded window or not through a PhoneWindow manager module.

In a possible implementation manner, the determining module 901 is further configured to call a native input manager module;

and forwarding the event to be processed to a PhoneWindowManager module through the native InputManager module.

In a possible implementation manner, the determining module 901 is further configured to determine whether the event to be processed includes a foreground processing tag when the foreground focal window is not an Activity window or the foreground focal window is not an embedded window;

It should be understood that the electronic device herein is embodied in the form of functional modules. The term "module" herein may be implemented in software and/or hardware, and is not specifically limited thereto. For example, a "module" may be a software program, a hardware circuit, or a combination of both that implements the functionality described above. The hardware circuitry may include application specific integrated circuits (application specific integrated circuit, ASICs), electronic circuits, processors (e.g., shared, proprietary, or group processors, etc.) and memory for executing one or more software or firmware programs, merged logic circuits, and/or other suitable components that support the described functions.

The application also provides an electronic device comprising: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, the one or more computer programs comprising instructions that, when executed by the electronic device, cause the electronic device to perform the event processing method as described in the first aspect or any of the possible implementations of the first aspect.

The present application also provides a computer readable storage medium having a computer program stored therein, which when executed by a processor causes the processor to perform the event processing method as described in the first aspect or any of the possible implementation manners of the first aspect.

The present application also provides a chip comprising a processor and a data interface, the processor reading instructions stored on a memory through the data interface, performing the event processing method of the first aspect or any one of the possible implementation manners of the first aspect.

Optionally, the chip may further comprise a memory, in which instructions are stored, the processor being configured to execute the instructions stored on the memory, the processor being configured to perform the event processing method of the first aspect or any of the possible implementations of the first aspect when the instructions are executed.

The memory may be read ∈only memory (ROM), other types of static storage devices that can store static information and instructions, random access memory (random access memory, RAM) or other types of dynamic storage devices that can store information and instructions, or may be an electrically erasable programmable read only memory (electrica llyerasable programmable read ∈only memory, EEPROM), a compact disc read only memory (compact disc read-only memory, CD ∈rom) or other optical disk storage, optical disk storage (including compact discs, laser discs, optical discs, digital versatile discs, blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other media that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, etc.

In this embodiment, "and/or" describes an association relationship of an association object, which means that there may be three relationships, for example, a and/or B, and may mean that there is a alone, a and B together, and B alone. Wherein A, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of the following" and the like means any combination of these items, including any combination of single or plural items. For example, at least one of a, b and c may represent: a, b, c, a ≡b, a ≡c, b ≡c, or a ≡b ≡c, wherein a, b, c may be single or plural.

Those of ordinary skill in the art will appreciate that the various elements and algorithm steps described in the embodiments disclosed herein can be implemented as a combination of electronic hardware, computer software, and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

In several embodiments provided herein, any of the functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in 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 specific embodiments of the present application, and any person skilled in the art may easily conceive of changes or substitutions within the technical scope of the present application, which should be covered by the protection scope of the present application. The protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An event processing method, characterized in that the event processing method comprises:

2. The event processing method as claimed in claim 1, wherein said determining whether the foreground focus window is an embedded window comprises:

extracting a zone bit in the foreground focus window parameter;

3. The event processing method as claimed in claim 2, wherein said extracting a flag bit in the foreground focus window parameter comprises:

4. The event processing method as claimed in claim 1, wherein before determining whether the foreground focus window is an embedded window, further comprising:

judging whether the foreground focus window is an Activity window or not;

5. The event processing method as claimed in claim 4, wherein said determining whether the foreground focus window is an Activity window comprises:

6. The event processing method as claimed in claim 1, wherein said callback of said event to be processed to said parent window to which said embedded window belongs comprises:

Canceling a foreground processing tag in the event to be processed;

7. The event processing method according to any one of claims 1 to 6, characterized by further comprising, before the acquisition of the event to be processed:

foreground processing tags are added to events to be processed.

8. The event processing method as claimed in any one of claims 1 to 6, wherein when the event to be processed is acquired, determining whether the foreground focus window is an embedded window comprises:

forwarding the event to be processed to a PhoneWindowManager function;

9. The event processing method as set forth in claim 8, wherein said forwarding said pending event to a PhoneWindowManager function comprises:

calling a native InputManager function;

10. The event processing method according to claim 1, further comprising:

11. An event processing apparatus, characterized in that the event processing apparatus comprises:

12. An electronic device, comprising: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, the one or more computer programs comprising instructions, which when executed by the electronic device, cause the electronic device to perform the event processing method of any of claims 1-10.

13. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program which, when executed by a processor, causes the processor to execute the event processing method according to any of claims 1 to 10.