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

Abstract

This application relates to the field of event handling technology, and provides an event handling method, apparatus, electronic device, and readable storage medium. The method includes: when an event to be processed is acquired, determining whether the foreground focus window is an embedded window; when the foreground focus window is an embedded window, calling back the event to be processed to the parent window to which the embedded window belongs; and having the host process corresponding to the parent window process the event to be processed, thereby transferring the event to be processed to the host process corresponding to the parent window for processing when an embedded window exists, realizing the interaction between the embedded window and its parent window.

Description

Technical Field

[0001] This application relates to the field of event processing technology, and in particular to an event processing method, apparatus, electronic device and readable storage medium. Background Technology

[0002] The window system provides embedded window display and interactive capabilities, supports quick task cards, and makes it convenient for users to use quick tasks efficiently.

[0003] When an application is launched as an embedded window, focus shifts to that window. System key events are passed to the embedded window by default, and therefore, the embedded window will consume these key events. Different key events in different scenarios will produce different response results, which can lead to unexpected outcomes. Examples are as follows:

[0004] In both new stack and unstack modes, when the embedded Task root Activity is displayed in the foreground, a Back event is triggered. In the native Android flow, this Back event is consumed by the Activity, and the business logic is to destroy the Activity. Ultimately, this results in the embedded window being destroyed while its parent window is not destroyed, causing a display error.

[0005] In the main stack reuse mode, when the embedded root Activity of the embedded Task is displayed in the foreground, the Back event is triggered. In the native Android process, the Back event will be consumed by the Activity. The business logic is to destroy the Activity and display other Activities under the Activity. Ultimately, the embedded window display area will display the embedded window that was not launched by the user. Summary of the Invention

[0006] This application provides an event handling method, apparatus, electronic device, and readable storage medium, with the aim of preventing events from being consumed by an embedded window and thus preventing interaction with the parent window.

[0007] Firstly, this application provides an event handling method, which includes:

[0008] When an event to be processed is received, determine whether the foreground focus window is an embedded window;

[0009] When the foreground focus window is an embedded window, the event to be processed is called back to the parent window to which the embedded window belongs;

[0010] The host process corresponding to the parent window handles the pending events.

[0011] The event handling method provided in this application determines whether the foreground focus window is an embedded window when an event to be processed is obtained; if the foreground focus window is an embedded window, the event to be processed is called back to the parent window to which the embedded window belongs; the host process corresponding to the parent window processes the event to be processed, thereby transferring the event to be processed to the host process corresponding to the parent window when an embedded window exists, realizing the interaction between the embedded window and its parent window.

[0012] In one possible implementation, determining whether the foreground focus window is an embedded window includes:

[0013] Extract the flag bits from the parameters of the foreground focus window;

[0014] When the parameter value of the flag bit is the first parameter value, the foreground focus window is determined to be an embedded window;

[0015] When the parameter value of the flag bit is the second parameter value, it is determined that the foreground focus window is not an embedded window.

[0016] In one possible implementation, extracting the flag bit from the foreground focus window parameters includes:

[0017] Extract the Task global variable mIsLaunchedFromHnEmbeddedWindow from the foreground focus window;

[0018] Use mIsLaunchedFromHnEmbeddedWindow as a flag in the parameters of the foreground focus window.

[0019] In one possible implementation, before determining whether the foreground focus window is an embedded window, the method further includes:

[0020] Determine if the foreground focus window is an Activity window;

[0021] When the foreground focus window is an Activity window, the step of determining whether the foreground focus window is an embedded window is executed.

[0022] In one possible implementation, determining whether the foreground focus window is an Activity window includes:

[0023] Determine whether the WindowState global variable mActivityRecord in the foreground focused window is empty;

[0024] When the WindowState global variable mActivityRecord is not null, the focus window corresponding to the event to be processed is determined to be the Activity window.

[0025] In one possible implementation, the step of calling back the event to be processed to the parent window to which the embedded window belongs includes:

[0026] Remove the foreground processing label from the pending event;

[0027] The pending events of the cancel foreground processing label will be called back to the parent window to which the embedded window belongs.

[0028] In one possible implementation, before acquiring the event to be processed, the process further includes:

[0029] Add a front-end processing tag to the events to be processed.

[0030] In one possible implementation, determining whether the foreground focus window is an embedded window when an event to be processed is received includes:

[0031] Forward the pending event to the PhoneWindowManager function;

[0032] The PhoneWindowManager function is used to determine whether the foreground focus window is an embedded window.

[0033] In one possible implementation, forwarding the event to be processed to the PhoneWindowManager function includes:

[0034] Call the NativeInputManager function;

[0035] The pending event is forwarded to the PhoneWindowManager function via the NativeInputManager function.

[0036] One possible implementation also includes:

[0037] When the foreground focus window is not an Activity window or the foreground focus window is not an embedded window, determine whether the event to be processed contains a foreground processing tag;

[0038] When the pending event contains a foreground processing label, the pending event is dispatched to the foreground focus window application;

[0039] If the pending event does not contain a foreground processing tag, the pending event will be discarded.

[0040] Secondly, this application provides an event processing apparatus, comprising:

[0041] The judgment module is used to determine whether the foreground focus window is an embedded window when an event to be processed is received;

[0042] The callback module is used to call back the event to be processed to the parent window of the embedded window when the foreground focus window is an embedded window;

[0043] The processing module is used to process the events to be processed by the host process corresponding to the parent window.

[0044] Thirdly, this application provides an electronic device, comprising:

[0045] One or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and the one or more computer programs include instructions that, when executed by the electronic device, cause the electronic device to perform an event handling method as described in any one of the first aspects or possible implementations of the first aspect above.

[0046] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform an event handling method as described in any one of the first aspects or possible implementations of the first aspect.

[0047] Fifthly, this application provides a chip, the chip including a processor and a data interface, the processor reading instructions stored in a memory through the data interface to execute the event processing method described in any one of the first aspects or possible implementations of the first aspect.

[0048] Optionally, as one possible implementation, the chip may further include a memory storing instructions, and the processor is configured to execute the instructions stored in the memory. When the instructions are executed, the processor is configured to perform the event handling method described in any one of the first aspects or possible implementations of the first aspect. Attached Figure Description

[0049] Figure 1 A schematic scenario diagram illustrating the processing of existing technology applications;

[0050] Figure 2 A schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0051] Figure 3A software structure block diagram of an electronic device provided in an embodiment of this application;

[0052] Figure 4 A flowchart illustrating an event handling method provided in one embodiment of this application;

[0053] Figure 5 A schematic diagram illustrating a scenario for launching an embedded window, which is provided by another embodiment of the event handling method of this application;

[0054] Figure 6 A schematic diagram of the display interface of an embedded window for an event handling method provided in another embodiment of this application;

[0055] Figure 7 A module interaction diagram for an embedded window startup of an event handling method provided in another embodiment of this application;

[0056] Figure 8 A flowchart illustrating an event handling method provided in another embodiment of this application;

[0057] Figure 9 This is a schematic diagram of the overall flow of an event handling method provided in another embodiment of this application;

[0058] Figure 10 A schematic diagram of the embedded window judgment process of an event handling method provided in another embodiment of this application;

[0059] Figure 11 A module interaction diagram of an event handling method provided in another embodiment of this application;

[0060] Figure 12 A flowchart illustrating an event handling method provided in another embodiment of this application;

[0061] Figure 13 This is a schematic diagram of the structure of an event processing device provided in this application. Detailed Implementation

[0062] The terms "first," "second," and "third," etc., used in this application specification, claims, and drawings are used to distinguish different objects, not to limit a specific order.

[0063] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0064] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to an event handling implementation scheme is given first:

[0065] Currently, the window system provides embedded window display and interaction capabilities, supporting quick task cards for convenient and efficient use of quick tasks. When an application is launched as an embedded window, the focus shifts to the embedded window. System key events are passed to the embedded window by default, and therefore, the embedded window consumes these key events. Different key events in different scenarios will have different response results, leading to unpredictable outcomes. For example: In new stack and unstack modes, when the embedded Task's root Activity is displayed in the foreground, triggering a Back event will be consumed by the embedded window in the native Android flow. The business logic is to destroy the Activity; ultimately, the embedded window is destroyed while its parent window is not, causing a display error. In the reused main stack mode, when the embedded Task's embedded root Activity is displayed in the foreground, triggering a Back event will be consumed by the embedded window in the native Android flow. The business logic is to destroy the Activity and display other Activities under it; ultimately, the embedded window's display area will show embedded windows not launched by the user, such as... Figure 1 The screen will then return to the embedded window and the WeChat chat interface.

[0066] To address the problems existing in the above-mentioned technical solutions, this application provides an event handling method. Upon receiving an event to be processed, the method determines whether the foreground focus window is an embedded window. If the foreground focus window is an embedded window, the event to be processed is redirected to the parent window of the embedded window. The host process corresponding to the parent window then processes the event. This method, when an embedded window exists, transfers the event to be processed to the host process corresponding to the parent window, thus enabling interaction between the embedded window and its parent window. The provided event handling method is applicable to mobile phones, tablets, desktops, laptops, notebooks, ultra-mobile personal computers (UMPCs), handheld computers, netbooks, personal digital assistants (PDAs), wearable electronic devices, smartwatches, and other electronic devices. The structure of an electronic device to which this event handling method is applicable can be as follows: Figure 2 As shown.

[0067] like Figure 2 As shown, Figure 2The following is an example diagram of the composition of an electronic device provided in this application. The electronic device 200 may include a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging 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, a headphone jack 270D, a sensor module 280, buttons 290, a motor 291, an indicator 292, a camera 293, a display screen 294, and a subscriber identification module (SIM) card interface 295, etc. The sensor module 280 may include a pressure sensor 280A, a gyroscope sensor 280B, a barometric pressure sensor 280C, a magnetic sensor 280D, an accelerometer 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, etc.

[0068] It is 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 illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0069] Processor 210 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0070] The controller can be the nerve center and command center of the electronic device 200. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

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

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

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

[0074] The wireless communication function of electronic device 200 can be implemented through antenna 1, antenna 2, mobile communication module 250, wireless communication module 260, modem processor, and baseband processor.

[0075] The wireless communication module 260 can provide solutions for wireless communication applications on the electronic device 200, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 260 can be one or more devices integrating at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 210. The wireless communication module 260 can also receive signals to be transmitted from processor 210, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0076] In some embodiments, antenna 1 of electronic device 200 is coupled to mobile communication module 250, and antenna 2 is coupled to wireless communication module 260, enabling electronic device 200 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

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

[0078] The display screen 294 of the electronic device 200 can display a series of graphical user interfaces (GUIs), which serve as the main screen of the electronic device 200. Generally, the size of the display screen 294 of the electronic device 200 is fixed, and only a limited number of controls can be displayed on the display screen 294. A control is a GUI element, a software component contained in an application, that controls all data processed by the application and interactive operations related to that data. Users can interact with controls through direct manipulation, thereby reading or editing information related to the application. Generally, controls can include visual interface elements such as icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets. For example, in this embodiment, the display screen 291 can display virtual buttons (one-click arrangement, start arrangement, scene arrangement).

[0079] Electronic device 200 can perform shooting functions through ISP, camera 293, video codec, GPU, display screen 294 and application processor.

[0080] Electronic device 200 can implement audio functions such as music playback and recording through audio module 270, speaker 270A, receiver 270B, microphone 270C, headphone jack 270D, and application processor.

[0081] In addition, an operating system runs on top of the aforementioned components. Examples include HarmonyOS, iOS, Android (open-source operating system), and Windows. Applications can be installed and run on this operating system.

[0082] Figure 3 This is a software structure block diagram of an electronic device provided in an embodiment of this application.

[0083] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments of this application, the software architecture of an electronic device includes at least three layers, from top to bottom: the application layer, the application framework layer, and the hardware abstraction layer.

[0084] The application layer may include a series of application packages. These application packages may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS. In some embodiments of this application, the application layer also includes embedded window services, embedded window modules, and embedded window interface modules. The embedded window service is a new module added to the SystemUI module, and the embedded window module is a new module added to the WM-Shell Lib module.

[0085] The embedded window module is used to implement the main functions of embedded window display interaction, including start / exit control, window display control, state synchronization, and event transmission.

[0086] The embedded window interface module is used to encapsulate the embedded window capability interface and provide it to the host process for invocation.

[0087] In some embodiments of this application, the application layer also includes the HnEmbeddedView module.

[0088] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions. For example... Figure 3As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc. The window manager is used to manage window programs. The window manager can obtain the screen size, determine whether there is a status bar, lock the screen, capture the screen, etc. In some embodiments of this application, the application framework layer also includes an adjusted AMS module, an adjusted WMS module, and a newly added embedded window interface set, as well as a NativeInputManager module and a PhoneWindowManager module. The PhoneWindowManager module includes a WindowState module and an ActivityTaskManageInternal module. The WindowState module includes the HnEmbeddedWindow method, the ActivityTaskManageInternal module includes the TakeoverKeyEventByHnEmbeddedWindow method, and the HnEmbeddedView module includes the onKeyEventOnTask method. The NativeInputManager module includes an InputDispatcher module, which includes the interceptKeyBeforeQueueing method and handleInterceptAction. The InputDispatcher module includes the dispatchOnceInnerLocked method. The WindowState module is a WMS submodule.

[0089] The revised AMS module is used to implement embedded Activity startup and lifecycle management.

[0090] The revised WMS module is used to implement embedded Task management, Task-based Activity transition control, embedded window scene focus and visibility management, config update and compatibility management.

[0091] The embedded window interface set is used to provide the system application with its own interface.

[0092] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0093] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0094] A phone manager is used to provide communication functions for electronic devices. For example, it manages call status (including connection and disconnection).

[0095] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0096] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0097] The hardware abstraction layer is the interface layer between the operating system kernel and the hardware circuit of the electronic device 200, and its purpose is to abstract the hardware.

[0098] For ease of understanding, the following embodiments of this application will be described using the following methods: Figure 2 and Figure 3 Taking the electronic device 200 with the structure shown as an example, the event processing method provided in the embodiments of this application will be specifically described in conjunction with the accompanying drawings and application scenarios.

[0099] Figure 4 This is a flowchart illustrating an event handling method provided in one embodiment of this application.

[0100] like Figure 4 As shown, the above event handling method may include:

[0101] Step S30: When an event to be processed is obtained, determine whether the foreground focus window is an embedded window.

[0102] In general, when users use high-frequency quick services such as scanning QR codes and payment codes, the operation is cumbersome. For example, they need to unlock the phone, open the application, and then select the corresponding service. When users use quick services while the screen is off, locked, or in application use, such as in online meetings or video calls, the operation is inconsistent and inconvenient. This embodiment provides embedded window display capabilities to the application window, supporting quick task cards to achieve efficient quick task window display. That is, during use, users can open the application through the embedded window by preset operations and directly use the quick service. The window system provides embedded window display and interaction capabilities, supporting quick task card Launcher, making it convenient for users to use quick tasks efficiently.

[0103] To enable opening applications via embedded windows, such as Figure 5 The diagram illustrates a scenario where an embedded window is launched. ① represents the main interface. By performing two back-side operations to launch the quick task card, the embedded window displays the WeChat payment application. Figure 6 The diagram shows the display interface of the embedded window, where 10 represents the embedded window with the application loaded, and 20 represents the parent window.

[0104] like Figure 7 The diagram showing the module interaction of the embedded window startup process demonstrates that when the startup operation of the target application is detected, the host process business is triggered. The host process sends a request to establish a connection with the embedded window service to the embedded window service. The embedded window service then sends a request to obtain 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. This enables direct communication between the host process and the embedded window module. The host process can be the process corresponding to the parent window.

[0105] After establishing a communication connection between the host process and the embedded window module, the host process first initializes and completes the drawing of the parent window. The specific drawing process is as follows: the host process sends an add parent window request to WMS, which includes placeholder image information and sends the window size of the parent window to the Graphics drawing module for window drawing. The host process also sends layer information to SurfaceFlinger for parent window layer composition. After the layer composition is completed, the parent window is displayed. Then, the host process sends a request to start the embedded window to the embedded window module. The request also includes startup parameters, including target window, window size, stack mode, touch mode, and Back mode. The target window represents the window of the corresponding application to be launched. The window size represents the size of the embedded window. The stack mode includes the application processing method in the embedded window, including new stack, unstack, and main stack reuse modes. The touch mode indicates whether the embedded window needs to have touch interactive controls. The Back mode indicates the application return processing method in the embedded window.

[0106] The embedded window module configures the target window, window mode, window size, embedded window flag, and stack mode based on the received startup parameters. The window mode indicates the display mode of the embedded window, including multi-window, picture-in-picture, or floating window modes. The embedded window flag identifies the window as embedded. The embedded window module sends the target window, window mode, window size, embedded window flag, and stack mode to the AMS module. The AMS module, based on the target window, sends the window mode and window size to the embedded application to launch the window. Then, it sends the embedded window flag and stack mode to the WMS module. The embedded application sends the window size to the WMS module to add the window. The WMS module draws the window based on the window size and dimensions. The process of drawing an embedded window using the WMS module includes: the embedded application sends the window size to the Graphics drawing module; the Graphics drawing module notifies the WMS module after drawing; the WMS module notifies the embedded window module that it has been created after drawing, and stack control is transferred to the embedded window module; the embedded window module then transfers stack control to the host process; and the host process performs layer composition to display the window. Specifically, the host process attaches a stack layer under SurfaceView and sends a configuration request to the SurfaceFlinger module to make the embedded application's stack layer visible. The SurfaceFlinger module then performs layer composition and, after completion, notifies the interaction module to display the interface, thus completing the startup of the embedded window.

[0107] In this embodiment, since embedded window startup is implemented, the foreground focus is generally on the embedded window after it is displayed. When a pending event is acquired, it is transmitted to the window corresponding to the foreground focus for processing. However, when the embedded window consumes pending events, in the new stack and unstack modes, if the embedded task's root activity is displayed in the foreground, a Back event is triggered. Under the native Android flow, this Back event is consumed, and the business logic is to destroy the Activity. This ultimately results in the embedded window being destroyed while its parent window is not destroyed, causing a display error. In the main stack reuse mode, if the embedded task's embedded root activity is displayed in the foreground, a Back event is triggered. Under the native Android flow, this Back event is consumed, and the business logic is to destroy the Activity and display other Activities under it. This ultimately results in the embedded window displaying an embedded window that was not launched by the user. Therefore, the pending events are transferred to the host process corresponding to the parent window for processing, realizing the interaction between the embedded window and its parent window.

[0108] In the specific implementation, in order to enable the interaction between the embedded window and its parent window, it is first determined whether the foreground focus window is an embedded window. If the foreground focus window is not an embedded window, the above problem will not occur. The above problem will only occur when the foreground focus window is an embedded window, thereby improving the efficiency of system processing.

[0109] Step S40: When the foreground focus window is an embedded window, the event to be processed is called back to the parent window to which the embedded window belongs.

[0110] It should be noted that, under normal circumstances, when the foreground focus window is an embedded window, the event to be processed is passed to the window corresponding to the foreground focus for processing. However, in this embodiment, the event to be processed is called back to the parent window to which the embedded window belongs, and the host process corresponding to the parent window processes the event to be processed, thereby realizing the interaction between the embedded window and its parent window.

[0111] Step S50: The host process corresponding to the parent window processes the event to be processed.

[0112] In this embodiment, when an event to be processed is obtained, it is determined whether the foreground focus window is an embedded window; if the foreground focus window is an embedded window, the event to be processed is called back to the parent window to which the embedded window belongs; the host process corresponding to the parent window processes the event to be processed, thereby transferring the event to be processed to the host process corresponding to the parent window when an embedded window exists, realizing the interaction between the embedded window and its parent window.

[0113] Figure 8 A flowchart illustrating an event handling method provided in another embodiment of this application is shown below. Figure 8 As shown, the above event handling method is based on the first embodiment, and step S30 includes:

[0114] Step S301: Extract the flag bit from the parameters of the foreground focus window.

[0115] In this embodiment, the foreground focus window parameter can be the Task global variable mIsLaunchedFromHnEmbeddedWindow, where Task is the task stack of the foreground focus window. The flag for identifying the embedded window can also be obtained from other parameters. This embodiment does not limit this. In this embodiment, the Task global variable mIsLaunchedFromHnEmbeddedWindow is used as an example for explanation.

[0116] Step S302: When the parameter value of the flag bit is the first parameter value, the foreground focus window is determined to be an embedded window.

[0117] It should be noted that the first parameter value can be true or other forms of parameter value. This embodiment does not limit this. When the parameter value of the flag bit is true, the foreground focus window is determined to be an embedded window.

[0118] Step S303: When the parameter value of the flag bit is the second parameter value, it is determined that the foreground focus window is not an embedded window.

[0119] It is understood that the second parameter value can be false, or it can be other forms of parameter value. This embodiment does not limit this. When the parameter value of the flag bit is false, it is determined that the foreground focus window is not an embedded window.

[0120] like Figure 9The overall process diagram shown illustrates that in a scenario where an embedded window is displayed in the foreground, the system key event is passed to the parent window of the embedded window, not the embedded window itself. The parent window then decides how to consume the event. When the key event is dispatched from NativeInputManager.interceptKeyBeforeQueueing to the PhoneWindowManager.interceptKeyBeforeQueueing method, it is determined whether the foreground focused window is an embedded window. If so, a callback interface notifies the host process, and a flag is set, while the ACTION_PASS_TO_USER flag is removed, preventing the event from being dispatched to the embedded window.

[0121] Step 2: When the embedded window is launched, a flag is set in the Task to identify it as an embedded Task. If the focused window is an embedded window, Step 2.1 is executed, and then the callback interface notifies the host process for processing. If the focused window is not an embedded window, Step 3 is executed directly. NativeInputManager.interceptKeyBeforeQueueing dispatches the key event to NativeInputManager.handleInterceptAction. NativeInputManager.handleInterceptAction sends the event to the InputDispatcher.dispatchOnceInnerLocked method, which checks whether the PhoneWindowManager return value contains ACTION_PASS_TO_USER. If it does, the event is dispatched to the foreground focused application; otherwise, it is discarded.

[0122] In one possible implementation, step S301 includes:

[0123] Extract the Task global variable mIsLaunchedFromHnEmbeddedWindow from the foreground focus window; and use mIsLaunchedFromHnEmbeddedWindow as a flag bit in the parameters of the foreground focus window.

[0124] In one possible implementation, prior to step S30, the method further includes:

[0125] Step S101: Determine whether the foreground focus window is an Activity window.

[0126] In this embodiment, since there are multiple types of windows, such as Activity windows or View windows, it is first determined whether the foreground focus window is an Activity window. This is because if the foreground focus window is not an Activity window, it is definitely not an embedded window. Therefore, before determining whether the embedded window is an Activity window, it is determined whether the foreground focus window is an Activity window, thereby improving the efficiency of system processing.

[0127] Step S102: When the foreground focus window is an Activity window, execute step S30.

[0128] In the specific implementation, the process of identifying the focused window as an embedded window is as follows: First, determine if the window is an Activity window, specifically by checking if the WindowState global variable mActivityRecord is null: WindowState.mActivityRecord != null; second, determine if the Task is an embedded Task, specifically by checking if the Task global variable mIsLaunchedFromHnEmbeddedWindow is true or false; in summary: if the window is both an Activity and its Task is also an embedded window Task, then the window is an embedded window.

[0129] like Figure 10 The diagram shows the embedded window detection process. First, it checks whether the focused window is an Activity window. If the focused window is not an Activity window, it checks whether the Task is an embedded Task. If the Task is an embedded Task, it returns true; if the focused window is not an Activity window, it returns false; if the Task is not an embedded Task, it returns false. This process is used to detect embedded windows.

[0130] like Figure 11The module interaction diagram shown illustrates that when the NativeInputManager module receives an event to be processed, it sends the event to the PhoneWindowManager module. The PhoneWindowManager module then sends a command to the WindowState module to determine if the foreground focused window is an embedded window. The WindowState module checks if the global variable mActivityRecord is null. If mActivityRecord is null, it returns the result to the PhoneWindowManager module, which then returns it to the NativeInputManager module. If mActivityRecord is not null, it checks if the foreground focused window is an embedded window. If it is, it cancels the foreground processing tag and sends a callback to the host window. The main process sends a request to the ActivityTaskManageInternal module, which then notifies the HnEmbeddedView module, which in turn notifies the host process for processing. If the foreground focus window is not an embedded window, the result is returned to the PhoneWindowManager module, which in turn returns the result to the NativeInputManager module. The NativeInputManager module sends the processed events to the InputDispatcher module. The InputDispatcher module determines whether the processed event contains a foreground processing tag. If it does, the event is dispatched to the foreground focus window application for processing. If it does not contain a foreground processing tag, the event is discarded.

[0131] In one possible implementation, step S101 includes:

[0132] Check if the WindowState global variable mActivityRecord is empty; if the WindowState global variable mActivityRecord is not empty, determine that the focus window corresponding to the event to be processed is the Activity window.

[0133] In the specific implementation, in order to determine whether the foreground focus window is an Activity window, the WindowState global variable mActivityRecord is checked for null. When the WindowState global variable mActivityRecord is not null, the focus window corresponding to the event to be processed is determined to be an Activity window. When the WindowState global variable mActivityRecord is null, the focus window corresponding to the event to be processed is determined to be an Activity window, thereby achieving accurate identification of the Activity window.

[0134] Figure 12 A flowchart of an event handling method provided in another embodiment of this application is shown below. Figure 12 As shown, the above event handling method is based on the first embodiment, and step S40 includes:

[0135] Step S401: Remove the foreground processing label from the event to be processed.

[0136] In this embodiment, the foreground processing label can be the ACTION_PASS_TO_USER flag, or other forms of flags. This embodiment does not limit this. In this embodiment, the ACTION_PASS_TO_USER flag is used as an example. When the foreground focus window is an embedded window, the callback interface notifies the host process and sets the flag, cancels the ACTION_PASS_TO_USER flag, and prevents the event from being dispatched to the embedded window. Therefore, by using the foreground processing label as the event processing label, the event is prevented from being dispatched to the embedded window.

[0137] Step S402: The pending event of canceling the foreground processing label is called back to the parent window to which the embedded window belongs.

[0138] In one possible implementation, prior to step S30, the method further includes:

[0139] Add a front-end processing tag to the events to be processed.

[0140] In this embodiment, when an event to be processed is obtained, a foreground processing tag is added to the event. After determining whether the focused window is an embedded window, the foreground processing tag is canceled or retained according to the determination result. For events whose foreground processing tags are canceled, they are prevented from being dispatched to the embedded window, thereby avoiding the embedded window from processing the event. Therefore, the processing window for the event can be determined by the foreground processing tag, thus achieving effective control over the event.

[0141] In one possible implementation, step S30 includes:

[0142] The pending event is forwarded to the PhoneWindowManager module; the PhoneWindowManager module then determines whether the foreground focus window is an embedded window.

[0143] In the specific implementation, in order to prevent the pending event from being directly dispatched to the embedded window for processing, after the pending event is obtained, it is not directly dispatched to the embedded window, but to the PhoneWindowManager module. The PhoneWindowManager module can determine whether the foreground focus window is an embedded window, thereby preventing the pending event from being directly dispatched to the embedded window for processing.

[0144] In one possible implementation, forwarding the event to be processed to the PhoneWindowManager module includes:

[0145] The NativeInputManager module is invoked; the pending event is forwarded to the PhoneWindowManager module through the NativeInputManager module.

[0146] In this embodiment, to prevent the pending events from being directly dispatched to the embedded window for processing, the pending events are instead forwarded to the PhoneWindowManager module. The PhoneWindowManager module determines whether the foreground focus window is an embedded window. To forward the pending events to the PhoneWindowManager module, communication is established between the NativeInputManager module and the PhoneWindowManager module. When a pending event is received, the NativeInputManager module forwards the pending event to the PhoneWindowManager module, which then determines whether the foreground focus window is an embedded window, thereby achieving effective control of the pending events.

[0147] One possible implementation also includes:

[0148] Determine whether the pending event contains a foreground processing label; if the pending event contains a foreground processing label, distribute the pending event to the foreground focus window application; if the pending event does not contain a foreground processing label, discard the pending event.

[0149] Continued Figure 9 The overall process diagram shown illustrates that when `NativeInputManager.interceptKeyBeforeQueueing` dispatches the key event to the `PhoneWindowManager.interceptKeyBeforeQueueing` method, it determines whether the foreground focused window is an embedded window. If so, a callback interface is used to notify the host process; otherwise, the processed result is returned to `NativeInputManager.interceptKeyBeforeQueueing`. `NativeInputManager.interceptKeyBeforeQueueing` then dispatches the key event to `NativeInputManager.handleInterceptAction`. `NativeInputManager.handleInterceptAction` sends the event to the `InputDispatcher.dispatchOnceInnerLocked` method, which checks if the `PhoneWindowManager` return value contains `ACTION_PASS_TO_USER`. If it does, the event is dispatched to the foreground focused application; otherwise, it is discarded. This ensures effective control over pending events.

[0150] Figure 13 This invention provides a schematic diagram of the structure of an event processing apparatus. The event processing apparatus 900 provided in this application includes:

[0151] The judgment module 901 is used to determine whether the foreground focus window is an embedded window when an event to be processed is obtained;

[0152] The callback module 902 is used to call back the event to be processed to the parent window to which the embedded window belongs when the foreground focus window is an embedded window;

[0153] The processing module 903 is used to process the event to be processed by the host process corresponding to the parent window.

[0154] In this embodiment, the event handling method provided in this application determines whether the foreground focus window is an embedded window when an event to be processed is obtained. If the foreground focus window is an embedded window, the event to be processed is called back to the parent window to which the embedded window belongs. The host process corresponding to the parent window processes the event to be processed, thereby transferring the event to be processed to the host process corresponding to the parent window when an embedded window exists, realizing the interaction between the embedded window and its parent window.

[0155] In one possible implementation, the judgment module 901 is further configured to extract the flag bit from the foreground focus window parameters;

[0156] When the parameter value of the flag bit is the first parameter value, the foreground focus window is determined to be an embedded window;

[0157] When the parameter value of the flag bit is the second parameter value, it is determined that the foreground focus window is not an embedded window.

[0158] In one possible implementation, the judgment module 901 is further configured to extract the Task global variable mIsLaunchedFromHnEmbeddedWindow from the foreground focus window;

[0159] Use mIsLaunchedFromHnEmbeddedWindow as a flag in the parameters of the foreground focus window.

[0160] In one possible implementation, the judgment module 901 is further configured to determine whether the foreground focus window is an Activity window;

[0161] When the foreground focus window is an Activity window, the step of determining whether the foreground focus window is an embedded window is executed.

[0162] In one possible implementation, the judgment module 901 is further configured to determine whether the WindowState global variable mActivityRecord in the foreground focus window is empty;

[0163] When the WindowState global variable mActivityRecord is not null, the focus window corresponding to the event to be processed is determined to be the Activity window.

[0164] In one possible implementation, the callback module 902 is further configured to cancel the foreground processing label in the event to be processed;

[0165] The pending events of the cancel foreground processing label will be called back to the parent window to which the embedded window belongs.

[0166] In one possible implementation, the callback module 902 is also used to add a foreground processing label to the event to be processed.

[0167] In one possible implementation, the judgment module 901 is further configured to forward the event to be processed to the PhoneWindowManager module;

[0168] The PhoneWindowManager module is used to determine whether the foreground focus window is an embedded window.

[0169] In one possible implementation, the judgment module 901 is also used to call the NativeInputManager module;

[0170] The pending events are forwarded to the PhoneWindowManager module via the NativeInputManager module.

[0171] In one possible implementation, the judgment module 901 is further configured to determine whether the event to be processed contains a foreground processing tag when the foreground focus window is not an Activity window or the foreground focus window is not an embedded window;

[0172] When the pending event contains a foreground processing label, the pending event is dispatched to the foreground focus window application;

[0173] If the pending event does not contain a foreground processing tag, the pending event will be discarded.

[0174] It should be understood that the electronic equipment described here is embodied in the form of functional modules. The term "module" here can be implemented in software and / or hardware, without specific limitation. For example, a "module" can be a software program, hardware circuit, or a combination of both that implements the above-described functions. The hardware circuit may include application-specific integrated circuits (ASICs), electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors) and memory for executing one or more software or firmware programs, integrated logic circuits, and / or other suitable components that support the described functions.

[0175] This application also 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, and the one or more computer programs include instructions that, when executed by the electronic device, cause the electronic device to perform an event handling method as described in any one of the first aspects or possible implementations of the first aspect above.

[0176] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform an event handling method as described in any one of the first aspects or possible implementations thereof.

[0177] This application also provides a chip, the chip including a processor and a data interface, the processor reading instructions stored in a memory through the data interface to execute the event handling method described in any one of the first aspects or possible implementations of the first aspect.

[0178] Optionally, the chip may further include a memory storing instructions, the processor being configured to execute the instructions stored in the memory, and when the instructions are executed, the processor being configured to perform the event handling method described in any one of the first aspects or possible implementations of the first aspect.

[0179] The memory can be read-only memory (ROM), other types of static storage devices that can store static information and instructions, random access memory (RAM), or other types of dynamic storage devices that can store information and instructions. It can also be electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices. Alternatively, it can be any other medium 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.

[0180] In this embodiment, "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following associated objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c can represent: a, b, c, a□b, a□c, b□c, or a□b□c, where a, b, and c can be single or multiple.

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

[0182] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0183] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0184] The above description is merely a specific embodiment of this application. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application. The protection scope of this application should be determined by the protection scope of the claims.

Claims

1. An event handling method, characterized in that, The event handling method includes: When an event to be processed is received, determine whether the foreground focus window is an embedded window; When the foreground focus window is an embedded window, the event to be processed is called back to the parent window to which the embedded window belongs; The host process corresponding to the parent window handles the pending events; When the foreground focus window is not an embedded window, determine whether the event to be processed contains a foreground processing tag; When the pending event contains a foreground processing label, the pending event is dispatched to the foreground focus window application; If the pending event does not contain a foreground processing tag, the pending event will be discarded.

2. The event handling method as described in claim 1, characterized in that, The step of determining whether the foreground focus window is an embedded window includes: Extract the flag bits from the parameters of the foreground focus window; When the parameter value of the flag bit is the first parameter value, the foreground focus window is determined to be an embedded window; When the parameter value of the flag bit is the second parameter value, it is determined that the foreground focus window is not an embedded window.

3. The event handling method as described in claim 2, characterized in that, Extracting the flag bits from the parameters of the foreground focus window includes: Extract the Task global variable mIsLaunchedFromHnEmbeddedWindow from the foreground focus window; Use mIsLaunchedFromHnEmbeddedWindow as a flag in the parameters of the foreground focus window.

4. The event handling method as described in claim 1, characterized in that, Before determining whether the foreground focus window is an embedded window, the method further includes: Determine if the foreground focus window is an Activity window; When the foreground focus window is an Activity window, the step of determining whether the foreground focus window is an embedded window is executed.

5. The event handling method as described in claim 4, characterized in that, The step of determining whether the foreground focus window is an Activity window includes: Determine whether the WindowState global variable mActivityRecord in the foreground focused window is empty; When the WindowState global variable mActivityRecord is not empty, the focus window corresponding to the event to be processed is determined to be the Activity window.

6. The event handling method as described in claim 1, characterized in that, The step of calling back the pending event to the parent window of the embedded window includes: Remove the foreground processing label from the pending event; The pending events of the cancel foreground processing label will be called back to the parent window to which the embedded window belongs.

7. The event handling method as described in any one of claims 1 to 6, characterized in that, Before the event to be processed is received, the process also includes: Add a front-end processing tag to the events to be processed.

8. The event handling method as described in any one of claims 1 to 6, characterized in that, The step of determining whether the foreground focus window is an embedded window when an event to be processed is obtained includes: Forward the pending event to the PhoneWindowManager function; The PhoneWindowManager function is used to determine whether the foreground focus window is an embedded window.

9. The event handling method as described in claim 8, characterized in that, The step of forwarding the event to be processed to the PhoneWindowManager function includes: Call the NativeInputManager function; The pending event is forwarded to the PhoneWindowManager function via the NativeInputManager function.

10. The event handling method as described in claim 4, characterized in that, Also includes: When the foreground focus window is not an Activity window, determine whether the event to be processed contains a foreground processing tag; When the pending event contains a foreground processing label, the pending event is dispatched to the foreground focus window application; If the pending event does not contain a foreground processing tag, the pending event will be discarded.

11. An event processing device, characterized in that, The event handling device includes: The judgment module is used to determine whether the foreground focus window is an embedded window when an event to be processed is received; The callback module is used to call back the event to be processed to the parent window of the embedded window when the foreground focus window is an embedded window; The processing module is used to process the pending event by the host process corresponding to the parent window. When the foreground focus window is not an embedded window, it determines whether the pending event contains a foreground processing label. When the pending event contains a foreground processing label, it distributes the pending event to the foreground focus window application. When the pending event does not contain a foreground processing label, it discards the pending event.

12. An electronic device, characterized in that, include: one or more processors; 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 including instructions that, when executed by the electronic device, cause the electronic device to perform the event handling method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the event handling method according to any one of claims 1 to 10.

Images