Call method and terminal device

Abstract

A call method and a terminal device, which relate to the technical field of terminals. After a Push end receives a call message and wakes up a main process of a VoIP application, the behavior of the VoIP application can be constrained, and thus the problems of increased overall power consumption and memory occupancy that are caused by the abuse of VoIP messages. A first application having a VoIP call function is installed in the terminal device. The method comprises: when a first application is not running in the foreground of a terminal device, the terminal device waking up a main process of the first application, and sending to the first application a first call message received by means of a Push channel, wherein the first call message is used for implementing a first VoIP call; and in response to the first call message, if the first application does not execute a first incoming call notification within a preset duration, the terminal device keeping the main process of the first application alive within the preset duration, wherein the first incoming call notification is used for outputting a first incoming call notification message for reminding a user.

Description

Calling methods and terminal equipment

[0001] This application claims priority to Chinese patent application filed on June 19, 2024, with application number 202410799406.4 and entitled "Method for Calling and Terminal Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of terminal technology, and in particular to communication methods and terminal devices. Background Technology

[0003] Currently, some applications (APPs) can use Voice Over Internet Protocol (VoIP) technology to make calls; these applications are simply referred to as VoIP applications. When a VoIP application runs in the background, the device may freeze or destroy the VoIP application process to reduce overall power consumption. In this case, to enable the VoIP application to make a call, the server can send the call message to the push client via a push channel. Then, upon receiving the call message, the push client will directly wake up the VoIP application's main process to deliver the call message. Subsequently, the VoIP application can handle processes such as process persistence and incoming call display within its own main process. However, in this approach, the VoIP application may perform actions unrelated to the VoIP call while its process is alive, leading to the misuse of VoIP messages and increasing overall power consumption and memory usage. Summary of the Invention

[0004] This application provides a call method and terminal device that can constrain the behavior of a VoIP application after receiving a call message on the Push end and waking up the main process of the VoIP application, thereby solving the problem of VoIP message abuse, increased power consumption and memory usage.

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

[0006] In a first aspect, a call method is provided, applied to a terminal device, wherein the terminal device has a first application with VoIP call functionality installed. The method includes: when the first application is not running in the foreground of the terminal device, the terminal device wakes up the main process of the first application and sends a first call message received through a Push channel to the first application, the first call message being used to implement a first VoIP call; in response to the first call message, if the first application does not provide a first incoming call notification within a preset time period, the terminal device keeps the main process of the first application active for the preset time period, wherein the first incoming call notification is used to output a first incoming call notification message to remind the user.

[0007] Based on the above technical solution, when an application with VoIP calling functionality is not running in the foreground of the terminal device, the terminal device can wake up the application's main process and send the call message received through the Push channel for implementing VoIP calling to the application. If the application does not output an incoming call notification message to remind the user within a preset time after receiving the call message, the terminal device keeps the application's main process active for that preset time. Thus, when the call message arrives at the terminal and wakes up the VoIP application's main process, if the VoIP application does not provide an incoming call notification within the preset time, the terminal device only keeps the VoIP application's main process active for that preset time. This constraint on VoIP application behavior addresses the issues of VoIP message abuse, increased power consumption, and memory usage.

[0008] In one possible design, the terminal device keeps the main process of the first application alive for a preset time period, including: keeping the main process of the first application alive for the preset time period; and freezing the main process of the first application when the preset time period is met. Thus, after keeping the VoIP application alive for the preset time period before waking it up, the terminal device freezes the main process of the VoIP application when the preset time period is met. If the VoIP application does not notify the user of an incoming call within the preset time period, its main process will be re-frozen. This not only constrains the behavior of the VoIP application, reducing the probability of VoIP message abuse, increased power consumption, and memory usage, but also allows the main process to be reawakened, resolving the issue of VoIP application crashes.

[0009] In one possible design, the method further includes: if, in response to the first call message, the first application executes the first incoming call notification within the preset duration, the terminal device continues to keep the main process of the first application active after the preset duration. Thus, if the VoIP application performs an incoming call notification within the preset duration, the terminal device can continue to keep the main process of the VoIP application active after the preset duration, ensuring that the VoIP application remains active and unfrozen during incoming calls and conversations.

[0010] In one possible design, the terminal device includes a Push terminal for transmitting call messages. The terminal device wakes up the main process of the first application and sends the first call message received through the Push channel to the first application. This includes the Push terminal waking up the main process of the first application and sending the first call message received through the Push channel to the first application. Thus, the terminal device can include a Push terminal. When the VoIP application is not running in the foreground, it can receive call messages sent through the Push channel through this Push terminal. The Push terminal can then wake up the VoIP application based on the call message and deliver the call message. This ensures that the VoIP application can receive call messages even when it is not running in the foreground, guaranteeing normal call execution.

[0011] In one possible design, the terminal device further includes a process resource management service, which is used to keep the main process of the first application alive and freeze it. Keeping the main process of the first application alive within a preset time period includes: the push client sending a first request to the process resource management service, the first request instructing the process resource management service to keep the main process of the first application alive within the preset time period; and in response to the first request, the process resource management service keeping the main process of the first application alive within the preset time period. Thus, the terminal device also includes a process resource management service, with the push client requesting the process resource management service to keep the VoIP application alive within the preset time period. In other words, the push client can act as a proxy for the VoIP application to request the keeping the main process of the VoIP application alive within the preset time period, eliminating the need for the VoIP application itself to handle keeping and freezing the main process. This can constrain the behavior of the VoIP application and reduce the probability of VoIP message abuse, increased overall power consumption, and memory usage.

[0012] In one possible design, the Push client sends a first request to the process resource management service, including: the Push client sending a first keep-alive request to the process resource management service, the first keep-alive request instructing the process resource management service to keep the main process of the first application alive; at a time that meets the preset duration, the Push client sends a first freeze request to the process resource management service, the first freeze request instructing the process resource management service to freeze the main process of the first application; in response to the first request, the process resource management service keeps the main process of the first application alive within the preset duration, including: in response to both the first keep-alive request and the first freeze request, the process resource management service keeps the main process of the first application alive within the preset duration.

[0013] In this way, the push client can first send a keep-alive request to the process resource management service to keep the VoIP application's main process alive. Then, after a preset time has elapsed since the moment the VoIP application's main process was woken up, the push client sends a freeze request to the process resource management service to refreeze the VoIP application's main process. This can constrain the behavior of the VoIP application after the main process is woken up, reducing the probability of VoIP message abuse, increased overall power consumption, and memory usage. Furthermore, by using the refreezing method, the application's main process can be reawakened, which can solve the problem of VoIP applications crashing.

[0014] In one possible design, the terminal device includes a Push client, a process resource management service, and a VoIP management service. The Push client is used to transmit call messages, the process resource management service is used to keep the main process of a first application alive and freeze it, and the VoIP management service is used to receive incoming call notifications. If, in response to the first call message, the first application sends the first incoming call notification within a preset time period, the terminal device continues to keep the main process of the first application alive after the preset time period, including: the Push client sending a first keep-alive request to the process resource management service, the first keep-alive request instructing the process resource management service to keep the main process of the first application alive; and in response to the first keep-alive request, the process resource management service keeps the first application alive. The first application, in response to the first call message, notifies the VoIP management service of the first incoming call within the preset time period; in response to the first incoming call notification, the VoIP management service sends a second keep-alive request to the process resource management service, the second keep-alive request instructing the process resource management service to keep the main process of the first application alive; at the moment the preset time period is met, the push client sends a first freeze request to the process resource management service, the first freeze request instructing the process resource management service to freeze the main process of the first application; in response to the second keep-alive request and the first freeze request, the process resource management service continues to keep the main process of the first application alive within the preset time period and after the preset time period.

[0015] In this way, the push client, acting as a proxy for the VoIP application, sends a keep-alive request to the process resource management service, keeping the VoIP application alive. If the VoIP application notifies the VoIP management service of an incoming call within a preset time period, the VoIP management service can also act as a proxy for the VoIP application and send a keep-alive request to the process resource management service, keeping the VoIP application alive. Subsequently, even if the push client, acting as a proxy for the VoIP application, sends a freeze request to the process resource management service again after the preset time period has elapsed since waking up the VoIP application's main process, the process resource management service can still keep the VoIP application's main process alive after the preset time period, meaning the process resource management service can choose not to respond to the push client's freeze request. This not only constrains the behavior of the VoIP application after waking up its main process, reducing the probability of VoIP message abuse, increased power consumption, and memory usage, but also ensures that the VoIP application remains active and unfrozen during incoming calls and conversations, thus guaranteeing the normal operation of the call.

[0016] In one possible design, the terminal device further includes a notification display service for displaying incoming call notification messages from the first application. After the first application, in response to the first call message, sends the first incoming call notification to the VoIP management service within the preset time period, the method further includes: in response to the first incoming call notification, the VoIP management service sends the first incoming call notification message from the first application to the notification display service; the notification display service displays the first incoming call notification message on the terminal device. Thus, when the VoIP application is not running in the foreground, the notification display service can replace the VoIP application in displaying the incoming call notification message.

[0017] In one possible design, the method further includes: when the first application is running in the foreground of the terminal device, the first application, in response to a second call message received via a long connection, sends a second incoming call notification to the VoIP management service; in response to the second incoming call notification, the VoIP management service sends the second incoming call notification message of the first application to the notification display service; the notification display service displays the second incoming call notification message on the terminal device. In this way, when the VoIP application is running in the foreground, the notification display service can also display the incoming call notification message, maintaining consistency with when the VoIP application is not running in the foreground and achieving a unified display entry point.

[0018] In one possible design, the first and second incoming call notification messages have the same style. This ensures that the display style of the incoming call notification messages is the same whether the VoIP application is running in the foreground or not, achieving a unified display style.

[0019] In one possible design, the first and second incoming call notification messages are not displayed in full screen, and both include caller information, an answer button, and a reject button. In this way, the incoming call notification messages are all non-full-screen notifications, and they directly contain caller information, answer buttons, and reject buttons. This not only distinguishes them from traditional native system incoming calls, solving the problem of easily misleading users, but also improves call connection efficiency.

[0020] In one possible design, the first incoming call notification message is displayed on the lock screen of the terminal device where a lock screen password is set. This first incoming call notification message allows the user to answer calls from the first application without unlocking the terminal device. In this way, the incoming call notification message can be directly displayed on the lock screen where a lock screen password is set, allowing the user to answer calls without unlocking the terminal device, thus achieving unlock-free answering and improving call connection efficiency.

[0021] In one possible design, the method further includes: the notification display service displays a reminder message in the status bar of the terminal device, the reminder message being used to remind that the call type corresponding to the first incoming call notification message is a VoIP call. In this way, the notification display service can display a reminder message in the status bar of the terminal device to indicate that the incoming call is a VoIP call, achieving strong reminder of VoIP calls. Furthermore, since the reminder message is located in the status bar, it is unaffected by whether the VoIP application is running in the foreground or background.

[0022] Secondly, a call method is provided, applied to a terminal device, wherein the terminal device has a first application with VoIP call functionality installed. The method includes: the terminal device displaying a first interface, the first interface being a lock screen interface with a lock screen password, the first interface displaying a first incoming call notification message of the first application, the first incoming call notification message occupying a portion of the first interface, the first incoming call notification message including a first answer button; the terminal device receiving a trigger operation on the first answer button; and in response to the trigger operation, without unlocking the terminal device, the terminal device connecting a first VoIP call corresponding to the first incoming call notification message.

[0023] Based on the above technical solution, the terminal device can display a lock screen interface with a password. This interface displays incoming call notifications from VoIP applications, occupying a portion of the screen. Incoming calls from VoIP applications are not displayed in full screen, thus differentiating them from the native call notification interface and preventing user confusion. Furthermore, the call notification includes an answer button. When the terminal device receives a trigger on this button, it can answer the VoIP call corresponding to the call notification without unlocking the device. This enables unlock-free answering, improving call connection efficiency.

[0024] In one possible design, the first incoming call notification message is either a voice call notification message or a video call notification message, and the first VoIP call is a voice call. In this way, the incoming call notification message is either a video call or a voice call, while the unlock-free process enables a voice call. That is, unlock-free voice calls can be achieved, allowing for quick answering of voice calls.

[0025] In one possible design, the first incoming call notification message is a video call notification message, and the first incoming call notification message also includes a second answer button; the method further includes: the terminal device receiving a trigger operation on the second answer button; in response to the trigger operation on the second answer button, the terminal device reminds the user to unlock the terminal device; if the terminal device is successfully unlocked, the terminal device connects the second VoIP call corresponding to the first incoming call notification message, the second VoIP call being a video call. In this way, when a video call notification message is received, the user needs to unlock the terminal device before a video call can be made, which ensures the privacy of the video call.

[0026] In one possible design, after the terminal device connects to the first VoIP call corresponding to the first incoming call notification message, the method further includes: the terminal device receiving an unlock operation; in response to the unlock operation, the terminal device displays a second interface and a first reminder message, wherein the second interface is the last interface displayed before the terminal device locks its screen, and the first reminder message is located in the status bar, and the first reminder message is used to remind the user that the incoming call type of the first VoIP call is a VoIP call, and / or the progress of the first VoIP call. In this way, after receiving the unlock operation, the terminal device can unlock the device and display the last interface displayed before locking its screen, as well as the reminder message in the status bar, i.e., the incoming call notification message is no longer displayed, thus avoiding obstruction of the user interface. This reminder message can be used to remind the user that the incoming call type is a VoIP call, the progress of the VoIP call, etc., so that the reminder message is unaffected by whether the VoIP application is running in the foreground or not in the background.

[0027] In one possible design, after the terminal device displays the second interface and the first reminder message, the method further includes: the terminal device receiving a trigger operation on the first reminder message; in response to the trigger operation, the terminal device displays a third interface and the first reminder message, wherein the third interface is a full-screen voice call interface. In this way, the user can also interact with the first reminder message to present a full-screen voice call interface; that is, the first reminder message supports user interaction, which can improve the user experience.

[0028] In one possible design, after the terminal device connects the first VoIP call corresponding to the first incoming call notification message, the method further includes: the terminal device receiving a trigger operation on the first incoming call notification message; in response to the trigger operation on the first incoming call notification message, the terminal device reminding the user to unlock the terminal device; if the terminal device is successfully unlocked, the terminal device displays a third interface and a first reminder message, wherein the third interface is a full-screen voice call interface, the first reminder message is located in the status bar, and the first reminder message is used to remind the user that the incoming call type of the first VoIP call is a VoIP call, and / or the progress of the first VoIP call.

[0029] In this way, the incoming call notification message displayed on the lock screen can be converted into a full-screen call interface. While the terminal device is displaying the full-screen call interface, the VoIP application is running in the foreground. In this scenario, the first notification message in the status bar is still displayed. In other words, the way the call progress is indicated is consistent whether the VoIP application is running in the foreground or in the background, improving the user experience.

[0030] In one possible design, the method further includes: the terminal device displaying a fourth interface, which is the running interface of the first application, and displaying a second incoming call notification message from the first application on the fourth interface. This second incoming call notification message is displayed in the notification center. In this way, when the terminal device displays the running interface of the VoIP application, the terminal device is running in the foreground. The received incoming call notification message can then be displayed in the notification center, meaning it is not a call notification message displayed by the VoIP application itself. This ensures that the way the VoIP application displays incoming call notification messages remains consistent whether it is running in the foreground or not.

[0031] Thirdly, a terminal device is provided, which has the function of implementing the method as described in the first aspect and any of the designs above. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function.

[0032] Fourthly, a terminal device is provided, including a processor and a memory, the memory being coupled to the processor, the memory storing computer program code including computer instructions, the processor reading the computer instructions from the memory to cause the terminal device to perform the method as described in the first or second aspect and any of the designs above. Optionally, the memory may be coupled to the processor or may be independent of the memory.

[0033] In one possible design, the terminal device also includes a display screen that can be used by the terminal device to perform display operations.

[0034] In one possible design, the terminal device also includes a communication interface that can be used to communicate with other devices (such as servers). For example, this communication interface can be a transceiver, input / output interface, interface circuit, output circuit, input circuit, pins, or related circuitry.

[0035] Fifthly, a computer-readable storage medium is provided, the computer-readable storage medium including a computer program that, when run on a terminal device, causes the terminal device to perform the method as described in the first or second aspect above and any one thereof.

[0036] In a sixth aspect, a computer program product is provided, the computer program product comprising: a computer program or instructions that, when executed on a computer, cause the computer to perform the method as described in the first or second aspect above and any one thereof.

[0037] A seventh aspect provides a chip system including at least one processor and at least one interface circuit, the at least one interface circuit being used to perform transceiver functions and send instructions to at least one processor, wherein when at least one processor executes instructions, at least one processor performs the method as described in either the first or second aspect above.

[0038] Eighthly, a communication system is provided, including a terminal device and a server, wherein the terminal device and the server cooperate to implement the method described in any of the designs of any of the above aspects. Optionally, the server may include at least one of a push server and an application server.

[0039] It should be noted that the technical effects of any of the designs in the third to eighth aspects mentioned above can be found in the technical effects of the corresponding designs in the first or second aspects, and will not be repeated here. Attached Figure Description

[0040] Figure 1 is a schematic diagram of a call method provided in an embodiment of this application;

[0041] Figure 2 is a schematic diagram of another call method provided in an embodiment of this application;

[0042] Figure 3 is a schematic diagram of the interface provided in an embodiment of this application;

[0043] Figure 4 is a schematic diagram of another call method provided in an embodiment of this application;

[0044] Figure 5 is a schematic diagram of the interface provided in an embodiment of this application;

[0045] Figure 6 is a schematic diagram of the interface provided in the embodiment of this application;

[0046] Figure 7 is a schematic diagram of the architecture of a communication system provided in an embodiment of this application;

[0047] Figure 8 is a structural schematic diagram of a terminal device provided in an embodiment of this application;

[0048] Figure 9 is a schematic diagram of the software structure of a terminal device provided in an embodiment of this application;

[0049] Figure 10 is a flowchart illustrating a call method provided in an embodiment of this application;

[0050] Figure 11 is a schematic diagram of the interface provided in the embodiment of this application;

[0051] Figure 12 is a schematic diagram of the interface provided in the embodiment of this application;

[0052] Figure 13 is a schematic diagram of a call answering process provided in an embodiment of this application;

[0053] Figure 14 is a schematic diagram of the interface provided in an embodiment of this application;

[0054] Figure 15 is a schematic diagram of the interface provided in an embodiment of this application;

[0055] Figure 16 is a schematic diagram of a rejection process provided in an embodiment of this application;

[0056] Figure 17 is a flowchart illustrating another call method provided in an embodiment of this application;

[0057] Figure 18 is a schematic diagram of the interface provided in an embodiment of this application;

[0058] Figure 19 is a flowchart illustrating another call method provided in an embodiment of this application;

[0059] Figure 20 is a structural schematic diagram of another terminal device provided in an embodiment of this application;

[0060] Figure 21 is a schematic diagram of the structure of a chip system provided in an embodiment of this application. Detailed Implementation

[0061] In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between the related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. A and B can be singular or plural.

[0062] In the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, a and b, a and c, b and c, a and b and c, where a, b, and c can be single or multiple.

[0063] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0064] VoIP (also known as IP telephony, internet telephony, broadband telephony, etc.) is a voice communication technology that enables calls over the internet. In one scenario, when an application using VoIP technology (hereinafter referred to as a VoIP application, including but not limited to social applications, conferencing applications, video applications, etc.) is running in the foreground of a device, it can establish a persistent connection with the server within its own process to enable communication. It receives call messages (or VoIP call messages, call request messages, etc.) from the server through this persistent connection. It can be understood that in this embodiment, a call message can refer to a call request message sent by the calling party. A persistent connection refers to a communication method where, after the client and server establish a connection and communicate, the connection is not actively closed after communication is completed, but rather maintained.

[0065] In another scenario, when a VoIP application is running in the foreground, it needs to send the call message via a push channel to enable communication. Figure 1 illustrates a call method provided in this embodiment. As shown in Figure 1, after the application server receives the call message from the calling party, it requests the push server to send the call message. Then, the push server sends the call message to the push client installed on the terminal device of the called party via the push channel. The push client can be a client responsible for receiving and processing push messages. Correspondingly, after receiving the call message, the push client directly wakes up (or launches) the main process of the VoIP application and delivers the call message to the VoIP application. Finally, the VoIP application establishes a call connection with the application server in its main process, and the user can then talk to the calling party after answering the call.

[0066] In this scheme, the Push client does not manage the VoIP application after delivering the call message; instead, the VoIP application handles processes such as process keep-alive and incoming call display within its own main process. This lack of control over the VoIP application's behavior after the main process is awakened means it may perform actions unrelated to the VoIP call while its process is active. This can lead to the misuse of VoIP messages, increasing overall power consumption and memory usage.

[0067] In this scenario, Figure 2 illustrates, for example, another call method provided in this application embodiment. As shown in Figure 2, when the application server receives a call message sent by the caller, it requests the Push server to send the call message. Then, the Push server sends the call message to the Push client installed on the terminal device of the called party through the Push channel. After receiving the call message, the Push client can act as a proxy for the VoIP application, connecting to the notification display service to display ordinary notification messages on behalf of the VoIP application. When the user performs an open operation such as clicking on the ordinary notification message, in response to the operation, the notification display service will wake up the main process landing page of the VoIP application. It can be understood that the landing page can refer to the application interface entered by opening the ordinary notification message, such as the incoming call interface 320 shown in Figure 3 (3) below. Finally, the VoIP application establishes a call connection with the application server in the main process, and the user can talk to the caller after answering the call.

[0068] In a locked screen scenario, when the user's action of opening a normal notification message is detected, the device will be unlocked first. For example, taking a mobile phone as the device and the Push application as an application on the phone, Figure 3 shows a schematic diagram of an interface provided by an embodiment of this application. As shown in Figure 3 (1), the mobile phone displays a lock screen interface 300, in which a normal notification message 301 is displayed. The normal notification message 301 is the normal notification message displayed by the notification display service. The normal notification message 301 does not display answer button, reject button, etc., and the aforementioned buttons can only be presented by opening the normal notification message 301. If the mobile phone detects an opening operation such as the user clicking on the normal notification message 301, it will trigger the phone to unlock first in response to the operation. The unlocking method may include, but is not limited to, face, fingerprint or password. Taking password as an example, the mobile phone can present an unlock interface 310 as shown in Figure 3 (2). When the user enters the mobile phone unlock password in the unlock interface 310, the mobile phone unlocks successfully. At the same time, the mobile phone can display the incoming call interface 320 shown in Figure 3 (3), which includes caller information 321 (such as avatar and name), answer button 322, reject button 323, etc.

[0069] In this solution, users need to perform multiple actions, such as opening a regular notification message, unlocking the device, and clicking the answer button, to answer the call. This process is cumbersome and leads to low connection efficiency. Furthermore, because the VoIP application's main process only establishes a connection with the application server after the user opens the regular notification message, this results in a longer call time and a poor user experience.

[0070] For example, Figure 4 shows a schematic diagram of another call method provided in this application embodiment. As shown in Figure 4, when the application server receives a call message sent by the caller, it requests the Push server to send the call message. Then, the Push server sends the call message to the Push client installed on the terminal device of the called party through the Push channel. Correspondingly, after receiving the call message, the Push client directly wakes up the main process of the VoIP application and delivers the call message to the VoIP application. At the same time, the Push client requires the VoIP application to notify the caller within a specified time, otherwise the main process will be destroyed. Then, the VoIP application establishes a call connection with the application server in advance and connects to the call management service to notify the caller within a specified time. Then, after receiving the call notification from the VoIP application, the call management service connects to the native call management service to display the caller in full screen, as shown in the caller interface 500 in the lock screen scenario in Figure 5 (1). Subsequently, the user can answer the call through the full-screen incoming call interface displayed by the native call management service. For example, the user can perform operations such as swiping on the answer button 501 included in the incoming call interface 500 shown in Figure 5 (1). In response to this operation, the call is connected. At the same time, the incoming call interface shown in Figure 5 (1) can jump to the call interface 510 shown in Figure 5 (2). Subsequently, the native call service will inform the VoIP application of the answer event. Accordingly, the VoIP application handles the answer event itself, and after informing the application server of the answer event, it can start a call with the caller.

[0071] In this solution, the VoIP application establishes a connection with the application server in advance, which solves the problems of delayed call reception and poor user experience present in the solution shown in Figure 2. However, in this solution, if the VoIP application fails to notify the user of an incoming call within the specified time, the main process will be forcibly destroyed. But if the user opens the VoIP application at the same time the main process is destroyed, for example, when the user opens the VoIP application through the VoIP application icon on the desktop, this will cause the VoIP application to crash.

[0072] Furthermore, the full-screen incoming call interface (incoming call interface 500 as shown in Figure 5(1)) and the call interface (call interface 510 as shown in Figure 5(2)) in this solution are too similar to the interface of native calls (i.e., traditional telephones), which can easily mislead users. Moreover, the incoming call display solution shown in Figure 4 is only applicable to voice calls. For video calls, the solution shown in Figure 2 (such as ordinary notification messages) is still used for display. Therefore, in the case of video calls, the problem of cumbersome answering operation and low connection efficiency in the solution shown in Figure 2 still exists.

[0073] Furthermore, regarding the two scenarios mentioned above—one based on long connections and the other based on push channels—in audio and video call scenarios, when a VoIP application switches to the background, it actively uses a floating window to remind the user of the call progress. The way the VoIP application reminds the user of the call progress differs depending on whether it's running in the background or in the foreground. For example, in the audio call scenario, as shown in Figure 6(1) on desktop 600, when the VoIP application is running in the background, it can remind the user of the call progress (such as call duration) through a floating window 601. When the VoIP application is running in the foreground, it can remind the user of the call progress through the call interface 610 shown in Figure 6(2). The inconsistent reminder methods in these two scenarios affect the user experience.

[0074] To address the aforementioned technical issues, this application provides a call method that, after waking the main process of a VoIP application on the receiving end of a call message, constrains the behavior of the VoIP application, reducing the probability of VoIP message abuse, increased overall power consumption, and higher memory usage, while also resolving the issue of VoIP applications crashing. Furthermore, it addresses the problem of the full-screen incoming call interface and call interface being too similar to the native call interface, which could mislead users, while enabling quick answering and improving connection efficiency. It also resolves the inconsistency in how VoIP applications display call progress notifications when running in the foreground versus the background.

[0075] For example, Figure 7 shows a schematic diagram of the architecture of a communication system for a call method application provided in an embodiment of this application. As shown in Figure 7, the communication system 700 includes a terminal device 701, an application server 702, and a push server 703, etc.

[0076] The terminal device 701 can be any device with VoIP applications installed. For example, the terminal device 701 may include, but is not limited to, mobile phones, tablets, desktop computers, laptops, handheld computers, ultra-mobile personal computers (UMPCs), netbooks, cellular phones, personal digital assistants (PDAs), artificial intelligence (AI) devices, wearable devices, in-vehicle devices, smart home devices, and / or smart city devices. Optionally, the terminal device 701 can be a fixed device or a portable device. This application embodiment does not impose any special limitations on the specific type of terminal device.

[0077] In some embodiments, terminal device 701 can act as the called party to receive call messages from the calling party (terminal device 704 as described below).

[0078] Application Server 702 can be a server used to provide services for VoIP applications. For example, it can provide a runtime environment for VoIP applications and manage resources such as VoIP application execution, database connections, and file systems. The application server can be used to process and respond to user requests, execute business logic, and manage data storage to ensure the stable and efficient operation of VoIP applications. In some embodiments of this application, when terminal device 701 is the called party, application server 702 can be responsible for receiving call messages from the calling party and sending the call messages to Push server 703. It can also be responsible for establishing a call connection with terminal device 701.

[0079] Push server 703 can be a server capable of implementing application message push functionality. Push server 703 can be used to process and send Push requests, pushing real-time messages or notifications to terminal devices. In some embodiments of this application, Push server 703 can be responsible for receiving call messages from application server 702 and sending the call messages to terminal device 701 through the Push channel.

[0080] Optionally, the application server 702 and the push server 703 can be devices or servers with computing capabilities, such as cloud servers or network servers. They can be a single server, a server cluster consisting of multiple servers, or a cloud computing service center.

[0081] It is understood that the embodiments of this application are based on the example of application server 702 and push server 703 being implemented as two different servers. In other embodiments, application server 702 and push server 703 can also be integrated together to be implemented as one server.

[0082] Optionally, the operating systems installed on terminal devices 701, application servers 702, and push servers 703 may include, but are not limited to, those that ... installed on terminal devices 701, application servers 702, and push servers 703. Or other operating systems. Of course, it's also possible to have no operating system installed.

[0083] Optionally, any two devices, such as terminal device 701, application server 702, and push server 703, can establish a connection through wired communication technology and / or wireless communication technology. The wireless communication technology includes, but is not limited to, at least one of the following: near field communication (NFC), Bluetooth (BT) (e.g., classic Bluetooth or Bluetooth Low Energy (BLE)), wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Zigbee, frequency modulation (FM), infrared (IR), and wide area networks relayed through relay devices.

[0084] For example, when the wireless communication technology is the aforementioned wide area network, the wireless communication technology can be a third-generation wireless telephone technology (3G) network, a fourth-generation mobile communication technology (4G) network, a fifth-generation mobile communication technology (5G) network, a future evolved public land mobile network (PLMN), or the Internet, etc.

[0085] It is understood that Figure 7 is a simplified schematic diagram for ease of understanding. In practical applications, the communication system shown in Figure 7 may also include other devices, such as terminal device 704. Terminal device 704 may also be various devices with VoIP applications installed. In some embodiments, terminal device 704 may act as the caller to send a call message to the called party (such as terminal device 701 described above). Terminal device 704 and terminal device 701 may be the same type of terminal device or different types of terminal devices. Other descriptions of terminal device 704 (such as communication method, device type, etc.) can be found in the corresponding description of terminal device 701.

[0086] For example, Figure 8 shows a schematic diagram of the structure of a terminal device provided in an embodiment of this application. As shown in Figure 8, the terminal device 701 may include a processor 810, a memory 820, a universal serial bus (USB) interface 830, a charging management module 840, a power management module 841, a battery 842, an antenna 1, an antenna 2, a mobile communication module 850, a wireless communication module 860, an audio module 870, a speaker 870A, a receiver 870B, a microphone 870C, buttons 880, a motor 891, a camera 892, a display screen 893, etc.

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

[0088] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

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

[0090] In some embodiments, the processor 810 may include one or more interfaces, such as a USB interface 830.

[0091] The memory 820 can be used to store computer executable program code, which includes instructions. The memory 820 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. The processor 810 executes various functional applications and data processing of the terminal device 701 by running instructions stored in the memory 820 and / or instructions stored in memory disposed within the processor.

[0092] The charging management module 840 receives charging input from the charger. While charging the battery 842, the charging management module 840 can also supply power to electronic devices through the power management module 841.

[0093] The power management module 841 is used to connect the battery 842, the charging management module 840, and the processor 810. The power management module 841 receives input from the battery 842 and / or the charging management module 840 to power the processor 810, memory 820, display 893, camera 892, and wireless communication module 860, etc.

[0094] The wireless communication function of the terminal device 701 can be implemented through antenna 1, antenna 2, mobile communication module 850, wireless communication module 860, modem processor, and baseband processor.

[0095] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in terminal device 701 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0096] The mobile communication module 850 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the terminal device 701.

[0097] The wireless communication module 860 can provide solutions for wireless communication applications on the terminal device 701, 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.

[0098] In some embodiments, antenna 1 of terminal device 701 is coupled to mobile communication module 850, and antenna 2 is coupled to wireless communication module 860, enabling terminal device 701 to communicate with networks and other devices (such as application server 702, push server 703, etc.) 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.

[0099] The audio module 870 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal.

[0100] The speaker 870A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The terminal device 701 can listen to hands-free calls through the speaker 870A.

[0101] The receiver 870B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the terminal device 701 receives a phone call or voice message, the receiver 870B can be brought close to the listener's ear to hear the voice.

[0102] The microphone 870C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to the microphone 870C, inputting the sound signal into the microphone 870C.

[0103] Buttons 880 include a power button, volume buttons, etc. Buttons 880 can be mechanical buttons or touch-sensitive buttons. Terminal device 701 can receive button input and generate key signal inputs related to user settings and function control of terminal device 701.

[0104] Motor 891 can generate vibration alerts, such as for incoming call vibration alerts.

[0105] Camera 892 is used to capture still images or videos. In some embodiments, terminal device 701 may include one or N cameras 892, where N is a positive integer greater than 1. In some embodiments of this application, the cameras can be used to capture images in video call scenarios.

[0106] The display screen 893 is used to display images, videos, etc. In some embodiments of this application, the display screen 893 can be used to display various interfaces and information involved in VoIP calls.

[0107] In some embodiments, the software architecture of the terminal device 701 may adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses a layered architecture as an example to exemplify the software architecture of the terminal device 701.

[0108] Figure 9 shows a schematic diagram of the software structure of a terminal device 701 provided in an embodiment of the present invention.

[0109] 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, the terminal device 701 may include two layers, from top to bottom: an application layer and a system service layer.

[0110] The application layer may include a series of application packages, such as VoIP applications. VoIP applications can be used to establish call connections with the application server to enable VoIP calls. They can also be used to handle events such as answering and hanging up. In some embodiments, when the VoIP application runs in the background of the terminal device 701, it can receive call messages from the application server through a push channel. In other embodiments, when the VoIP application runs in the foreground of the terminal device 701, it can also receive call messages from the application server through a persistent connection.

[0111] The system server layer can include a series of system services, such as the Push client, process resource management service, VoIP management service, and notification display service. The Push client can receive call messages sent by the Push server through the Push channel and deliver these call messages to the VoIP application. It can also be used to manage the VoIP application process by waking it up (or unfreezing), keeping it alive, or freezing it (or removing it from the keep-alive list). The process resource management service is responsible for performing operations such as waking up, keeping alive, and freezing the VoIP application process. For example, the process resource management service can allocate the necessary system resources (including but not limited to memory resources, hard disk resources, processor resources, etc.) to the VoIP application process to wake it up and keep it alive; or, the process resource management service can reclaim the system resources occupied by the VoIP application process to freeze it. The VoIP management service can be used to receive and process incoming call notification messages from VoIP applications, which can originate from push channels or persistent connections. It can also be used to publish call information, handle answering or ending VoIP calls, and manage the keep-alive functionality of VoIP application processes. The notification display service is responsible for displaying VoIP call-related information, such as incoming call information.

[0112] It is understood that, in this embodiment of the application, keeping the main process of the VoIP application alive allows the main process to remain running in memory. Freezing the main process of the VoIP application only temporarily suspends the main process and does not terminate or destroy its execution. Once the main process needs to be run again, it can be awakened and quickly resumed.

[0113] The above classification of system services according to function can be used in practice. For example, multiple system services can be integrated together, or they can be classified in a more granular way according to the multiple functions contained in each system service.

[0114] It is understood that the structures illustrated in Figures 8 and 9 do not constitute a specific limitation on the terminal device 701. In other embodiments of this application, the terminal device 701 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.

[0115] For details regarding the hardware and software structure of terminal device 704, please refer to the structural description of terminal device 701. For details regarding the structure of push server 703 and application server 702, please refer to the description of terminal device 701 shown in Figure 8. Optionally, push server 703 or application server 702 may include more or fewer components than shown in Figure 8; for example, push server 703 or application server 702 may only include a processor, memory, and communication interface (or communication module).

[0116] The technical solutions involved in the following embodiments can all be implemented in devices with the structures shown in Figures 8 and 9, and in systems with the architecture described in Figure 7. The following description uses terminal device 701 as the terminal device, push server 703 as the push server, and application server 702 as the application server.

[0117] For example, Figure 10 shows a flowchart of a call method provided in an embodiment of this application. As shown in Figure 10, the method includes the following steps:

[0118] S1001, The application server sends a call message to the push server. Correspondingly, the push server receives the call message from the application server.

[0119] The call message can be a call message sent by the calling party, such as a call message sent by a VoIP application installed on the calling party. For example, taking the calling party as terminal device 704, as shown in Figure 11(1), terminal device 704 can display the running interface 1100 of the VoIP application. The running interface of the VoIP application can contain one or more contacts or groups. The user can select any of the contacts or groups to make a voice call or video call. If the terminal device detects that the user has performed a click operation on contact 1, in response to the operation, as shown in Figure 11(2), terminal device 704 displays a chat interface 1110 with contact 1. The user can call the video call control or the voice call control in the chat interface 1110 to make a video call or a voice call with the contact.

[0120] For example, the chat interface 1110 may include a function button 1111. The terminal device 704 detects a user's click operation on the function button 1111. In response to this operation, as shown in Figure 11(3), the terminal device 704 displays a voice call control 1121, a video call control 1122, etc. In response to the user's trigger operation on the voice call control 1121 or the video call control 1122, the application server can obtain the call message from the terminal device 704.

[0121] It is understood that Figure 11 is only an example of an operation for generating call messages for a VoIP application on terminal device 704. In other embodiments, the operation for generating call messages for a VoIP application can be various key operations, gesture operations, voice operations, etc.

[0122] It can also be understood that in the embodiments of this application, the call message can be a call message for voice calls or a call message for video calls.

[0123] S1002. The Push server sends a call message to the Push client through the Push channel. Correspondingly, the Push client receives the call message from the Push server.

[0124] S1003: The Push-side proxy VoIP application requests the process resource management service to keep the main process of the VoIP application alive.

[0125] S1004, Process Resource Management Service keeps the main process of VoIP applications alive.

[0126] In some embodiments, a VoIP application may have multiple proxies, such as push clients and VoIP management services. In this embodiment, the process resource management service can keep the main process of the VoIP application alive at the granularity of the proxies (or agents). That is, the process resource management service can keep the main process of the VoIP application alive according to the keep-alive instructions requested by each proxy of the VoIP application.

[0127] In some scenarios, the process resource management service can simultaneously receive different instructions from different agents of a VoIP application. For example, assuming the different agents of a VoIP application are a push client and a VoIP management service, the push client requests the process resource management service to keep the VoIP application's main process alive, while the VoIP management service requests to freeze the VoIP application's main process. In this case, responding to the instructions from both agents, the process resource management service can keep the VoIP application's main process alive. That is, the instruction to keep the VoIP application's main process alive has a higher priority than the instruction to simultaneously freeze the VoIP application's main process, thus ensuring the VoIP application can function normally.

[0128] S1005. The Push client wakes up the main process of the VoIP application and delivers the call message. Correspondingly, the VoIP application receives the call message from the Push client.

[0129] In this way, after receiving a call message from the Push server, the Push client first wakes up the main process of the VoIP application. It then uses a proxy VoIP application to connect to the process resource management service to request unfreezing and keep-alive functionality, ensuring that the VoIP application is not frozen during incoming calls and conversations. Furthermore, since waking up the main process of the VoIP application takes some time, executing step S1005 first, followed by step S1006, allows the VoIP application sufficient time to notify the user of incoming calls.

[0130] S1006. Push terminal constraint VoIP application to notify incoming calls within a specified time.

[0131] In some embodiments, the Push client can constrain the VoIP application to notify users of incoming calls within a specified time by setting a freeze timer. Specifically, after executing step S1005, the Push client starts the freeze timer and begins counting down. When the specified duration is reached, the main process of the VoIP application is refrozen. Optionally, in this embodiment, the Push client can also, as shown in step S1003, proxy the VoIP application to request the process resource management service to refreeze the main process of the VoIP application.

[0132] Optionally, the push client can set freeze timers at the application and call granularity. That is, freeze timers can be set separately for different VoIP applications, and freeze timers can be set separately for different calls within the same VoIP application. This allows for separate keep-alive and freeze operations for the main processes of different VoIP applications, ensuring that the operation of different VoIP applications does not interfere with each other. Similarly, for different calls within the same VoIP application, keep-alive and freeze operations for the main process can be performed separately, ensuring that different call processes do not interfere with each other.

[0133] In this way, after the push client wakes up the VoIP application's main process, it can constrain the VoIP application to notify the user of incoming calls within a specified time by setting a freeze timer or similar method. If the VoIP application fails to notify the user of incoming calls within the specified time, its main process will be re-frozen. Alternatively, when the process resource management service can keep the VoIP application's main process alive at the agent level, if no other agent requests to keep the VoIP application's main process alive, it will also be re-frozen. This not only constrains the behavior of VoIP applications, reducing the probability of VoIP message abuse, increased overall power consumption, and memory usage, but also allows the application's main process to be reawakened by re-freezing, thus resolving the issue of VoIP applications crashing.

[0134] Of course, in other embodiments, after executing step S1005, the Push client can monitor the behavior of the VoIP application within a specified time period. If it is determined that the VoIP application has not notified the user of an incoming call within the specified time, the main process of the VoIP application can be re-frozen. Conversely, if it is determined that the VoIP application has notified the user of an incoming call within the specified time, the main process of the VoIP application can remain unfrozen. Optionally, the Push client can determine whether the VoIP application has notified the user of an incoming call within the specified time period from feedback messages from other services (such as the VoIP management service). Optionally, in this implementation, the Push client can also start a timer. If it is determined that the VoIP application has not notified the user of an incoming call before the specified time period expires, the timer can be turned off, and the main process of the VoIP application will remain alive. Conversely, if it is determined that the VoIP application has not notified the user of an incoming call when the specified time period expires, the main process of the VoIP application can be re-frozen.

[0135] Optionally, in addition to performing steps S1003, S1005 to S1006 as described above, the Push terminal can also perform operations such as verifying the legality of the call message and deduplication, which can ensure the security of the call process. These operations will not be described in detail in this article.

[0136] Steps S1001 to S1006 describe the process of receiving a call. The following describes the process of notifying a VoIP application of an incoming call. For example, as shown in Figure 10, this process includes steps S1007 to S1014.

[0137] S1007, VoIP applications establish call connections with application servers.

[0138] In this way, the VoIP application establishes a connection with the application server before the user answers the call—that is, a pre-established connection. Compared to establishing a connection with the application server after the user answers the call, this reduces call latency and improves the user experience.

[0139] S1008, VoIP application generates incoming call information.

[0140] The incoming call information may include one or more of the following: caller information (such as avatar, name, etc.) and notification landing page address. The notification landing page address can be used to index the landing page displayed by the VoIP application when the call interface is opened via the incoming call notification, such as interface 1510 shown in Figure 15(2) and video screen 1520 shown in Figure 15(3).

[0141] In some embodiments, the VoIP application can execute step S1008 after successfully establishing a connection with the application server in step S1007. Conversely, if the connection with the application server fails, step S1008 can be skipped. This saves the overhead of the terminal device generating incoming call information. Of course, in other embodiments, steps S1007 and S1008 can also be executed simultaneously.

[0142] S1009. The VoIP application registers at least one of the following events with the VoIP management service: accepting a call or rejecting a call.

[0143] The answer event can be used by the VoIP management service to notify the VoIP application of an answer event when it determines that a user has performed an answer operation. The reject event can be used by the VoIP management service to notify the VoIP application of a reject event when it determines that a user has performed a reject operation.

[0144] Optionally, steps S1008 and S1009 can be executed synchronously or sequentially. When executed sequentially, the embodiments of this application do not restrict the order of execution.

[0145] S1010: The VoIP application notifies the VoIP management service of incoming calls. Correspondingly, the VoIP management service receives the incoming call notifications from the VoIP application.

[0146] Optionally, the incoming call notification may include the incoming call information as described in step S1008. This adds an incoming call notification capability to the VoIP management service, allowing VoIP applications to notify the VoIP management service of incoming calls.

[0147] S1011. The VoIP management service, acting as an agent, requests the process resource management service to keep the VoIP application's main process alive. Correspondingly, the process resource management service keeps the VoIP application's main process alive.

[0148] In some embodiments, before performing step S1011, the VoIP application may also verify the legitimacy of the incoming call information, and after the verification is successful, perform step S1011.

[0149] Thus, by executing step S1011, a new proxy for the process resource management service, namely the VoIP management service, is added. The VoIP management service, acting as a proxy for the VoIP application, requests to keep the VoIP application's main process alive. Even if the freeze timer mentioned in step S1006 expires, the VoIP application's main process can still be kept alive instead of refreezing the VoIP application's main process in response to the freeze timer.

[0150] Of course, in conjunction with the solutions in other embodiments described in step S1006, since the VoIP application will not be re-frozen after it notifies the incoming call within a specified time, that is, there is no scenario where the main process of the VoIP application needs to be re-frozen when the freeze timer expires. Therefore, the VoIP management service does not need to execute step S1011.

[0151] S1012, VoIP management service generates incoming call notifications.

[0152] In some embodiments, the VoIP management service can generate an incoming call notification based on incoming call information from a VoIP application. This notification may include one or more of the following: caller information, an answer button, and a reject button. The answer button can be used to receive a user's answering action, and the reject button can be used to receive a user's rejecting action. Optionally, in this embodiment, the answer button and the reject button can be implemented using different controls, or they can be implemented by performing different operations on the same control.

[0153] S1013. The VoIP management service sends an incoming call notification to the notification display service. Correspondingly, the notification display server receives the incoming call notification from the VoIP management service.

[0154] Optionally, after the VoIP management service executes step S1013, the screen of the terminal device can also be turned on.

[0155] S1014. Notification display service displays incoming call notifications.

[0156] Optionally, the notification display service can display incoming call notifications on the lock screen, notification center, etc. It is understood that the lock screen in this example is a password-protected lock screen; in other embodiments, the lock screen can also be a password-free lock screen.

[0157] For example, taking a voice call scenario as an example, Figure 12(1) shows a schematic diagram of an incoming call notification provided in an embodiment of this application. As shown in Figure 12(1), the terminal device displays a lock screen interface 1200 (which can be used as an example of a first interface), in which an incoming call notification 1201 (which can be used as an example of a first incoming call notification message) is displayed. The incoming call notification 1201 can display caller information 1201a (such as name, avatar, etc., only the name is shown in Figure 12(1)), answer button 1201b (which can be used as an example of a first answer button), reject button 1201c, etc. The incoming call notification 1201 allows the user to answer the voice call (which can be used as an example of a first VoIP call) or reject the voice call without unlocking the terminal device. Optionally, the incoming call notification 1201 can also display an identifier for the incoming voice call, such as "xx application voice".

[0158] Taking a video call scenario as an example, Figure 12(2) shows another schematic diagram of incoming call notification provided by the embodiment of this application. As shown in Figure 12(2), the terminal device displays a lock screen interface 1210, in which an incoming call notification 1211 is displayed (which can also be used as an example of the first incoming call notification message). The incoming call notification 1211 can display caller information 1211a (such as name, avatar, etc., only the name is shown in Figure 12(2)), answer button 1211b (which can be used as an example of the second answer button), reject button 1211c, etc. The incoming call notification 1211 allows the user to answer the video call after unlocking the terminal device (which can be used as an example of the second VoIP call). Alternatively, it allows the user to reject the video call without unlocking the terminal device. Optionally, the incoming call notification 1211 can also display a video call identifier, such as "xx application video". Optionally, in video call scenarios, users can also choose to make voice calls only. For example, the incoming call notification 1211 shown in Figure 12(2) can also display an answer button 1211d (which can also be used as an example of the first answer button). Through this answer button 1211d, users can make voice calls without unlocking the terminal device. In other words, the incoming call notification 1211 can also enable users to answer voice calls without unlocking the terminal device.

[0159] It is understandable that in a non-locked screen video call scenario, the video call notification received by the terminal device (such as the call notification shown in Figure 12 (4)) may also include an answer button 1211d so that the user can choose to make a voice call.

[0160] Optionally, while performing step S1014, the VoIP application can also ring and vibrate. Of course, this ringing and vibration operation can also be performed by other services (such as VoIP management services), and this embodiment of the application does not specifically limit this.

[0161] Steps S1007 to S1014 describe the process of notifying VoIP applications of incoming calls. The answering process is described below. For example, Figure 13 shows a schematic diagram of an answering process provided in an embodiment of this application. As shown in Figure 13, the process includes the following steps:

[0162] S1301, The notification display service receives the user's answering operation.

[0163] For example, the answering operation can be a click operation on the answer button 1201b or answer button 1211b shown in Figure 12. Of course, the answering operation can also be a trigger operation on the answer button included in the incoming call notification displayed on the unlock screen. Alternatively, the answering operation can also be other voice operations or gesture operations.

[0164] S1302. The notification display service informs the VoIP management service of the call answering operation. Correspondingly, the VoIP management server receives the call answering operation notification from the notification display service.

[0165] In some embodiments, taking a voice call scenario as an example, the terminal device can execute steps S1303 to S1307.

[0166] S1303. The VoIP management service notifies the VoIP application of the audio answer event. Accordingly, the VoIP application receives the audio answer event from the VoIP management service.

[0167] In some embodiments, the VoIP management service may execute step S1303 based on step S1009 shown in FIG10, whereby the VoIP application registers a call-answering event with the VoIP management service.

[0168] S1304. The VoIP application sends an audio answer command to the application server. Correspondingly, the application server receives the audio answer command from the VoIP application.

[0169] In this case, the VoIP application can send an audio answer command to the application server through the call connection established in step S1007 as shown in Figure 10.

[0170] Audio stream transmission between S1305, VoIP applications, and application servers.

[0171] Once the application server returns a successful answer to the VoIP application, audio stream transmission can occur between the VoIP application and the application server, allowing the user to make an audio call. Using this audio answering method, the user can successfully answer the call by performing an operation such as clicking the answer button 1201b shown in Figure 12 (1). That is, in a locked screen scenario, voice answering can be achieved in one step through the incoming call notification 1201, saving answering steps, simplifying operations, and improving connection efficiency.

[0172] S1306. The VoIP application reports a successful call answering event to the VoIP management service. Correspondingly, the VoIP management service receives the successful call answering event reported by the VoIP application.

[0173] S1307, VoIP management service integration notification display service transforms incoming call notifications into in-call notifications.

[0174] The call notification can be used to remind users that a voice call is in progress.

[0175] For example, in conjunction with the incoming call notification 1201 shown in Figure 12(1), the incoming call notification 1201 can be converted into the call notification 1401 included in the lock screen interface 1200 shown in Figure 14(1). As shown in Figure 14(1), the call notification 1401 may include a microphone button 1401a, a speaker button 1401b, a hang-up button 1401c, etc. Optionally, the hang-up button 1401c and the reject button 1201c shown in Figure 12(1) can be implemented as the same button, or they can be implemented as different buttons.

[0176] In some embodiments, taking a video call scenario as an example, the terminal device may execute steps S1308 to S1311.

[0177] S1308, VoIP management service triggers user unlock.

[0178] In some embodiments, the VoIP management service can connect to a notification display service or other services to display an unlock interface to trigger user unlocking. For example, in conjunction with the incoming call notification 1211 shown in Figure 12 (2), when the user performs an operation such as clicking the answer button 1211b, in response to this operation, as shown in Figure 15 (1), the terminal device can display an unlock interface 1500, where the user can enter a password to unlock the device. Of course, in other embodiments, the VoIP management service can also trigger user unlocking in other ways, such as facial recognition, fingerprint recognition, etc.

[0179] S1309, VoIP management service launches the video call landing page of the VoIP application main process.

[0180] Optionally, the video call landing page can be generated by the VoIP application and sent to the VoIP management service by executing step S1010 shown in Figure 10.

[0181] In some embodiments, the video call landing page of the VoIP application main process can be an interface that reminds the user that a call is being answered. For example, when the terminal device is unlocked in a manner as shown in Figure 15 (1), the terminal device can display the interface 1510 in the call as shown in Figure 15 (2), which is the video call landing page of the VoIP application main process.

[0182] Similarly, in audio call scenarios, the terminal device can also display a notification reminding the user that a call is being answered. For example, in conjunction with the incoming call notification 1201 shown in Figure 12(1), when the user performs an answering operation such as clicking the answer button 1201b, in response to this operation, before displaying the call notification 1401 shown in Figure 14(1), the terminal device can also display a notification that a call is being answered. For example, the notification that a call is being answered can be changed from the "xx application voice" text included in the incoming call notification 1201 to a notification with the text "connecting." Similarly, the VoIP management service can display the notification that a call is being answered through the notification display service.

[0183] Of course, in other embodiments, since the connection process is faster, the interface or notification during the connection may not be visible to the user. Alternatively, in other embodiments, the terminal device may not display the interface or notification during the connection, but directly present the notification or interface after the connection is made. That is to say, in this embodiment, the video connection landing page may also be the video screen 1520 shown in Figure 15 (3) below.

[0184] S1310, the VoIP application sends a video call answering command to the application server. Correspondingly, the application server receives the video call answering command from the VoIP application.

[0185] In this case, the VoIP application can send a video call answering instruction to the application server through the call connection established in step S1007 as shown in Figure 10.

[0186] S1311 enables video streaming between VoIP applications and application servers.

[0187] Once the application server returns a successful call response to the VoIP application, video streaming can then occur between the VoIP application and the application server.

[0188] At the same time, the VoIP application can also display video footage. For example, after a successful call, the interface 1510 shown in Figure 15(2) can jump to the video screen 1520 shown in Figure 15(3), and the user can then make a normal call.

[0189] Figure 13 describes the call handling process; the call rejection process will be described below. For example, Figure 16 shows a schematic diagram of a call rejection process provided in an embodiment of this application. As shown in Figure 16, the process includes the following steps:

[0190] S1601, The notification display service receives rejection operations performed by the user.

[0191] For example, the rejection operation can be a click operation on the rejection button 1201c or rejection button 1211c shown in Figure 12. Of course, the rejection operation can also be triggered by the rejection button included in the incoming call notification displayed on the unlock screen. Alternatively, the rejection operation can also be other voice operations or gesture operations.

[0192] S1602. The notification display service informs the VoIP management service of the rejection operation. Correspondingly, the VoIP management server receives the rejection operation notification from the notification display service.

[0193] S1603. The VoIP management service notifies the VoIP application of the rejection event. Correspondingly, the VoIP application receives the rejection event from the VoIP management service.

[0194] In some embodiments, the VoIP management service may execute step S1603 based on step S1009 shown in FIG10, whereby the VoIP application registers a rejection event with the VoIP management service.

[0195] S1604. The VoIP application sends a rejection command to the application server. Correspondingly, the application server receives the rejection command from the VoIP application.

[0196] In this case, the VoIP application can send a rejection command to the application server through the call connection established in step S1007 as shown in Figure 10.

[0197] The call ends when the application server returns a successful rejection.

[0198] S1605. The VoIP application reports a successful rejection event to the VoIP management service. Correspondingly, the VoIP management service receives the successful rejection event reported by the VoIP application.

[0199] S1606, VoIP management service integration notification display service delete incoming call notification.

[0200] For example, the incoming call notification may be Incoming Call Notification 1201, Incoming Call Notification 1211, etc., as shown in Figure 12.

[0201] S1607. The VoIP management service, acting as an agent for the VoIP application, requests the process resource management service to freeze the main process of the VoIP application.

[0202] Steps S1606 and S1607 can be executed simultaneously or sequentially. When executed sequentially, this application does not limit the order.

[0203] S1608, The Process Resource Management Service freezes the main process of the VoIP application.

[0204] The above describes the call process of sending call messages through the Push channel. It can be understood that in this embodiment, when a call message is sent through the Push channel, the VoIP application is not running in the background. Before receiving the call message from the caller, the terminal device can display a lock screen interface or an unlocked screen interface (such as a desktop, or the running interface of other applications besides the VoIP application). In the above embodiment, the terminal device displays a lock screen interface as an example. When the terminal device displays an unlocked screen interface, taking the desktop as an example, as shown in Figure 12 (3), the terminal device can display desktop 1220, in which a voice call notification 1221 can be displayed. As shown in Figure 12 (4), the terminal device can display desktop 1230, in which a video call notification 1231 can be displayed. Both the voice call notification 1221 and the video call notification 1231 can be displayed in the notification center.

[0205] Since the video call notification 1231 is displayed on the unlocked screen, the user can answer the call without unlocking the device. When the user answers the call via the answer button in the video call notification 1231, the terminal device can directly display the interface 1510 shown in Figure 15(2), or directly display the video screen 1520 shown in Figure 15(3), etc.

[0206] For an introduction to the controls or information in the voice call notification 1221 and video call notification 1231, please refer to the descriptions of the corresponding controls or information in Figure 12 (1) and (2). For the display of the voice call notification 1221 and video call notification 1231, as well as the implementation of answering and rejecting calls through the voice call notification 1221 and video call notification 1231, please refer to the implementation of call notifications shown in Figure 12 (1) and (2).

[0207] The following describes the call process of sending call messages via a long connection. It can be understood that in this embodiment, when a call message is sent via the Push channel, the VoIP application runs in the foreground. Before receiving the call message from the calling party, the terminal device can display any running interface of the VoIP application.

[0208] In this long-connection scenario, Figure 17 shows a flowchart of another call method provided by an embodiment of this application. As shown in Figure 17, the method includes the following steps:

[0209] S1701, the application server sends a call message to the VoIP application through a long-lived connection channel. Correspondingly, the VoIP application receives the call message from the application server.

[0210] This long-connection channel can be a long-term connection channel established between a VoIP application and the application server when the application is running in the foreground.

[0211] S1702, VoIP application generates incoming call information.

[0212] S1703, A VoIP application registers at least one of the following events with the VoIP management service: a call answering event or a call rejection event.

[0213] S1704. The VoIP application notifies the VoIP management service of incoming calls. Correspondingly, the VoIP management service receives incoming call notifications from the VoIP application.

[0214] S1705, The VoIP Management Service, acting as an agent for the VoIP application, requests the Process Resource Management Service to keep the main process of the VoIP application alive.

[0215] In the scheme shown in Figure 17, although there is no freeze timer, the main process of the VoIP application may be frozen due to various reasons such as the VoIP application being switched to run in the background. By executing step S1705, the main process of the VoIP application can be included, so that the main process of the VoIP application can be active normally during incoming calls and calls.

[0216] S1706, Process Resource Management Service keeps the main process of VoIP applications alive.

[0217] S1707, VoIP management service generates incoming call notifications.

[0218] S1708, the VoIP management service sends an incoming call notification to the notification display service. Correspondingly, the notification display server receives the incoming call notification from the VoIP management service.

[0219] S1709, Notification display service displays incoming call notifications.

[0220] For a description of each step shown in Figure 17, please refer to the description of the corresponding steps shown in Figure 10.

[0221] Currently, when a VoIP application is running in the foreground, the incoming call information displayed is generated by the VoIP application itself, and this information is an in-app notification containing caller information, answer buttons, and reject buttons. When a VoIP application is running in the background, the incoming call information displayed is generated by the device system, and this information can be a regular notification message or a full-screen incoming call interface. The display entry and style are inconsistent in these two scenarios. The solution provided in this application, as shown in Figures 10 and 17, unifies the display entry (e.g., lock screen interface or notification center) and display style (e.g., both are non-full-screen incoming call notifications, and both include caller information, answer buttons, and reject buttons) in both scenarios. Furthermore, the solution provided in this application has the system service proxy handle the keep-alive function for the VoIP application during incoming call notifications and calls, eliminating the need for the VoIP application to handle keep-alive operations.

[0222] For example, in a long-connection scenario, incoming call notifications can be voice call notification 1801 (which can be an example of a second incoming call notification message) presented in interface 1800 (which can be used as an example of a fourth interface) as shown in Figure 18 (1), or video call notification 1811 presented in interface 1810 (which can be used as an example of a fourth interface) as shown in Figure 18 (2). Both voice call notification 1801 and video call notification 1811 can be displayed in the notification center. It is understood that interfaces 1800 and 1810 are both running interfaces of VoIP applications. In this embodiment, the running interface is taken as a chat interface, but the running interface can also be other interfaces, such as the main interface, the Moments interface, and other various running interfaces.

[0223] Similarly, in this scenario, video call notification 1811 allows users to answer calls without unlocking their phones. For an explanation of the call notification shown in Figure 18, please refer to the related information shown in Figure 12.

[0224] Optionally, for the answering and rejecting processes in long-connection scenarios, please refer to the relevant implementation in the Push channel scenario.

[0225] Based on the incoming call notification provided in this application embodiment, it not only supports answering calls without unlocking, but also simplifies the answering operation, improves the connection efficiency, and can be distinguished from the system's native call interface, thus avoiding misleading users.

[0226] In some embodiments, in addition to displaying the aforementioned notifications, the terminal device may also display VoIP call reminder information. This reminder information is unaffected by whether the VoIP application is running in the foreground; that is, regardless of whether the VoIP application is running in the foreground, the terminal device can continuously display the VoIP call reminder information. Based on the reminder information provided in the embodiments of this application, the method by which VoIP applications remind users of call progress during the answering process can be standardized, thereby improving the user experience.

[0227] As one possible implementation, the VoIP call notification information includes at least one of incoming call notification and in-call notification. Optionally, the incoming call notification, in-call notification, etc., can be presented in a capsule style in the status bar, or in other forms, or in an area included in all running interfaces except the status bar. For example, the incoming call notification can be used to remind the user that the incoming call is from a VoIP application (or a VoIP call), as shown in Incoming Call Notification 10 in Figures 12, 15 (1), (2), and 18. The in-call notification can be used to remind the user that the incoming call is from a VoIP application, or to remind the user of the progress of the VoIP call, as shown in In-Call Notification 20 in Figures 14 and 15 (3).

[0228] Optionally, when the terminal device displays incoming call reminder 10, if it detects that the user has performed an answering operation, in response to the answering operation, after the answer is successful, the terminal device can change incoming call reminder 10 to call reminder 20.

[0229] In some embodiments, the above-mentioned reminder information may support user actions.

[0230] For example, in conjunction with the lock screen interface 1200 shown in Figure 14(1), when a user performs an unlocking operation on the lock screen interface 1200, such as clicking on an area other than the call notification 1401 or swiping up from the bottom, the terminal device can display the password interface 1410 shown in Figure 14(2) (which can be used as an example to remind the user to unlock the terminal device). The user can enter a password in the password interface 1410 to unlock the terminal device. After successful unlocking, the terminal device can jump to the desktop 1420 shown in Figure 14(3) (which can be used as an example of the second interface). In the lock screen interface 1200, the password interface 1410, and the desktop 1420, a call notification 20 (which can be used as an example of the first notification message) is displayed.

[0231] It is understood that Figure 14 (3) is based on the example of the terminal device last displaying the desktop before locking the screen. In other embodiments, if the terminal device last displays other running interfaces besides the desktop before locking the screen, the terminal device can also display other running interfaces displaying call reminders 20 after unlocking the lock screen interface 1200 shown in Figure 14 (1).

[0232] When a user performs an open operation such as clicking on the call notification 1401 in the lock screen interface 1200 shown in Figure 14(1), the terminal can also display the password interface 1410 shown in Figure 14(2) in response to the operation. After the user unlocks the terminal device, the terminal device can display the full-screen call interface 1430 shown in Figure 14(4) in response to the user's unlock operation. The call notification 20 is also displayed in the full-screen call interface 1430.

[0233] Users can switch between the desktop 1420 shown in Figure 14(3) and the full-screen call interface 1430 shown in Figure 14(4) through the call reminder 20. When the terminal device detects a user's click operation on the call reminder 20 shown in Figure 14(3), in response to the operation, the terminal device can present the full-screen call interface 1430 shown in Figure 14(4) (which can be used as an example of a third interface).

[0234] Alternatively, the user can switch between the lock screen interface 1200 shown in Figure 14(1) and the full-screen call interface 1430 shown in Figure 14(4) via the call reminder 20. For example, if the terminal device detects a user's click operation on the call reminder 20 shown in Figure 14(1), in response to the operation, the terminal device can also present the password interface 1410 shown in Figure 14(2) to remind the user to unlock the device. When the user successfully unlocks, in response to the user's unlocking, the terminal device can present the full-screen call interface 1430 shown in Figure 14(4).

[0235] Optionally, the full-screen call interface 1430 shown in Figure 14 (4) may also include a button 1431. When the terminal device detects a user's click operation on the button 1431, in response to the operation, the terminal device may hide the full-screen call interface 1430, such as the terminal device may return to the desktop 1420 shown in Figure 14 (3).

[0236] The above example uses the call answering operation performed through the call notification in the lock screen scenario as an example. Similarly, when the call answering operation is performed through the call notification in the notification center scenario, the switching between the interface containing the call notification and the full-screen call interface can also be realized. For example, when the user performs the answering operation through the answer button in the call notification 1221 shown in Figure 12 (3), in response to the operation, the terminal device can display the desktop 1420 shown in Figure 14 (3). Subsequently, the switching between the desktop 1420 shown in Figure 14 (3) and the full-screen call interface 1430 shown in Figure 14 (4) can be realized through the call reminder 20. The same applies to the call notification 1801 shown in Figure 18 (1).

[0237] The above example uses a voice call scenario. Optionally, a video call scenario is similar. The terminal device can respond to user operations during a call by switching between different interfaces, such as the video screen and the last interface displayed before the terminal device locks, or the video screen and an interface containing incoming call notifications.

[0238] The above example uses the call reminder 20 as an example. In other examples, users can also use the call reminder 10 to display a full-screen incoming call interface (such as a full-screen incoming call interface with call reminder 10 as shown in Figure 14 (4)), a full-screen call interface (such as a full-screen interface with call reminder 10 as shown in Figure 15 (2)).

[0239] In this embodiment, when executing processes such as those shown in Figures 10 and 17, the VoIP management service, in addition to connecting with the notification display service to display incoming call notifications, can also connect with the notification display service to display the aforementioned VoIP call reminder information. For example, in the incoming call notification stage as shown in Figure 10, the VoIP management service can connect with the notification display service to display incoming call reminder 10. As another example, in the answering scenario shown in Figure 13, the VoIP application can also report a successful answering event to the VoIP management service, and the VoIP management service can also connect with the notification display service to update incoming call reminder 10 to a call in progress reminder 20. Similarly, in the scenario shown in Figure 16, the VoIP management service can also connect with the notification display service to delete incoming call reminder 10.

[0240] For example, Figure 19 shows a flowchart of another call method provided in an embodiment of this application. This method can be applied to a terminal device that has a first application with VoIP call functionality installed, such as the VoIP application described above. For example, as shown in Figure 19, the method includes the following steps:

[0241] S1901, If ​​the first application is not running in the foreground of the terminal device, the terminal device wakes up the main process of the first application and sends the first call message received through the Push channel to the first application.

[0242] The first call message (the call message in the process shown in Figure 10) is used to implement the first VoIP call. For details on the implementation of the first call message, please refer to the relevant implementation of the call message shown in Figure 10.

[0243] In some embodiments, the terminal device includes a Push terminal as described above, which can be used to transmit call messages, and step S1901 can be performed by the Push terminal.

[0244] S1902. In response to the first call message, if the first application fails to execute the first call notification within a preset time period, the terminal device keeps the main process of the first application running for a preset time period.

[0245] The first incoming call notification is used to output a notification message to remind the user of the first incoming call. For example, the preset duration can be the specified time as described above, and the first incoming call notification can be the incoming call notification shown in Figure 10, and the first notification message can be the incoming call notification shown in Figure 10.

[0246] In some embodiments, keeping the main process of the first application alive within a preset time period can be specifically implemented by keeping the main process of the first application alive within a preset time period after the time when the main process of the first application is woken up, and freezing the main process of the first application when the preset time period is met after the time when the main process of the first application is woken up.

[0247] In some embodiments, the terminal device includes a process resource management service as described above. The terminal device can use the Push client and the process resource management service to keep the main process of the first application alive within a preset time period.

[0248] As one possible implementation, the Push client sends a first request to the process resource management service, instructing the process resource management service to keep the main process of the first application alive for a preset time period. In response to the first request, the process resource management service keeps the main process of the first application alive for the preset time period. Optionally, the first request can be implemented as one or more requests.

[0249] Taking the first request as an example of multiple requests, the Push client can send a first keep-alive request to the process resource management service. The first keep-alive request instructs the process resource management service to keep the main process of the first application alive, as shown in step S1003 of Figure 10. When the time elapsed since the first application's main process was woken up meets a preset time limit, the Push client sends a first freeze request to the process resource management service. The first freeze request instructs the process resource management service to freeze the main process of the first application, as shown in step S1006 of Figure 10. Correspondingly, in response to the first keep-alive request and the first freeze request, the process resource management service keeps the main process of the first application alive within the preset time limit, as shown in steps S1004 and S1006 of Figure 10.

[0250] In some embodiments, the method shown in FIG19 may further include step S1903.

[0251] S1903. In response to the first call message, if the first application executes the first call notification within a preset time period, the terminal device continues to keep the main process of the first application alive after the preset time period.

[0252] In some embodiments, the terminal device includes a Push client, a process resource management service, and a VoIP management service as described above. The VoIP management service can be used to receive incoming call notifications. For a description of the Push client and the process resource management service, please refer to the corresponding descriptions above. The terminal device can use the Push client, the process resource management service, and the VoIP management service to keep the main process of the first application alive after a preset time.

[0253] As one possible implementation, the Push client sends a first keep-alive request to the process resource management service, instructing the process resource management service to keep the main process of the first application alive, as shown in step S1003 of Figure 10. In response to the first keep-alive request, the process resource management service keeps the main process of the first application alive, as shown in step S1004 of Figure 10. In response to the first call message, the first application sends a first call notification to the VoIP management service within a preset time period, as shown in step S1010 of Figure 10. In response to the first call notification, the VoIP management service sends a second keep-alive request to the process resource management service, instructing the process resource management service to keep the main process of the first application alive, as shown in step S1011 of Figure 10. When the preset time period from waking up the main process of the first application is met, the Push client sends a first freeze request to the process resource management service, instructing the process resource management service to freeze the main process of the first application, as shown in step S1006 of Figure 10. In response to the second keep-alive request and the first freeze request, the process resource management service continues to keep the main process of the first application alive for a preset period of time and after the preset period of time.

[0254] In some embodiments, the terminal device further includes a notification display service as described above, which can be used to display incoming call notification messages from the first application. After the first application responds to the first call message and performs a first incoming call notification to the VoIP management service within a preset time period, the VoIP management service sends the first incoming call notification message of the first application to the notification display service in response to the first incoming call notification, as shown in step S1013 of FIG10. The notification display service displays the first incoming call notification message on the terminal device, as shown in step S1014 of FIG10. For example, the first incoming call notification message may be the incoming call notification message shown in FIG12.

[0255] In some embodiments, when the first application is running in the foreground of the terminal device, the first application, in response to a second call message received via a long connection (the call message shown in FIG17), performs a second call notification to the VoIP management service (the call notification shown in FIG17). In response to the second call notification, the VoIP management service sends the first application's second call notification message (the call notification shown in FIG17) to the notification display service, as shown in step S1708 of FIG17. The notification display service displays the second call notification message on the terminal device, as shown in step S1709 of FIG17.

[0256] The above primarily describes the solutions provided by the embodiments of this application from a methodological perspective. It is understood that, in order to achieve the above functions, the terminal device includes hardware structures and / or software modules corresponding to the execution of each function. Based on the units and algorithm steps of the various examples described in the embodiments disclosed in this application, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by a computer driving hardware 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 to exceed the scope of the technical solutions of the embodiments of this application.

[0257] This application provides embodiments that can divide a terminal device into functional modules based on the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional module. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0258] Figure 20 shows a schematic diagram of a terminal device provided in an embodiment of this application. The terminal device 2000 can be used to implement the methods executed by the terminal device described in the above method embodiments. For example, the terminal device 2000 may include a processing unit 2001, a communication unit 2002, and a display unit 2003.

[0259] The processing unit 2001 is used to support the terminal device 2000 in performing the processing function described in any one of Figures 1 to 19; the communication unit 2002 is used to support the terminal device 2000 in performing the communication function described in any one of Figures 1 to 19; and the display unit 2003 is used to support the terminal device 2000 in performing the display function described in any one of Figures 1 to 19.

[0260] Optionally, the terminal device 2000 shown in FIG20 may further include a storage unit (not shown in FIG20) that stores programs or instructions. When the processing unit 2001 executes the program or instructions, the terminal device 2000 shown in FIG20 can perform the method described in the above-described method embodiments.

[0261] The technical effects of the terminal device 2000 shown in Figure 20 can be referred to the technical effects described in the above method embodiments, and will not be repeated here. The processing unit 2001 involved in the terminal device 2000 shown in Figure 20 can be implemented by a processor or processor-related circuit components, and can be a processor or processing module. The communication unit 2002 can be implemented by a transceiver or transceiver-related circuit components, and can be a transceiver or transceiver module. The display unit 2003 can be implemented by display screen-related components.

[0262] This application also provides a chip system, as shown in FIG21, which includes at least one processor 2101 and at least one interface circuit 2102. The processor 2101 and the interface circuit 2102 are interconnected via lines. For example, the interface circuit 2102 can be used to receive signals from other devices. As another example, the interface circuit 2102 can be used to send signals to other devices (e.g., the processor 2101). Exemplarily, the interface circuit 2102 can read instructions stored in a memory and send the instructions to the processor 2101. When the instructions are executed by the processor 2101, the terminal device can perform the various steps executed by the terminal device in the above embodiments. Of course, the chip system may also include other discrete devices, which are not specifically limited in this application.

[0263] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0264] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application does not specifically limit the type of memory or the arrangement of the memory and processor.

[0265] For example, the chip system may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0266] It should be understood that each step in the above method embodiments can be completed by integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0267] This application also provides a computer storage medium storing computer instructions, which, when executed on a terminal device, cause the terminal device to perform the methods described in the above-described method embodiments.

[0268] This application provides a computer program product, which includes a computer program or instructions that, when run on a computer, cause the computer to perform the methods described in the above-described method embodiments.

[0269] In addition, this application also provides an apparatus, which may specifically be a chip, component or module. The apparatus may include a connected processor and a memory. The memory is used to store computer execution instructions. When the apparatus is running, the processor can execute the computer execution instructions stored in the memory to cause the apparatus to perform the methods in the above-described method embodiments.

[0270] In this embodiment, the terminal device, computer storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0271] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0273] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0275] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of 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.

[0276] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions 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 scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for making a call, characterized in that, Applied to a terminal device, wherein the terminal device has a first application with VoIP calling functionality installed, the method includes: When the first application is not running in the foreground of the terminal device, the terminal device wakes up the main process of the first application and sends a first call message received through the Push channel to the first application. The first call message is used to implement a first VoIP call. If, in response to the first call message, the first application fails to execute the first incoming call notification within a preset time period, the terminal device keeps the main process of the first application active within the preset time period, wherein the first incoming call notification is used to output a first incoming call notification message to remind the user.

2. The method according to claim 1, characterized in that, The method further includes: In response to the first call message, if the first application executes the first call notification within the preset time period, the terminal device continues to keep the main process of the first application active after the preset time period.

3. The method according to claim 1 or 2, characterized in that, The terminal device includes a Push terminal, which is used to transmit call messages; The terminal device wakes up the main process of the first application and sends the first call message received through the Push channel to the first application, including: The Push terminal wakes up the main process of the first application and sends the first call message received through the Push channel to the first application.

4. The method according to claim 3, characterized in that, The terminal device also includes a process resource management service, which is used to keep the main process of the first application alive and freeze it. The terminal device keeps the main process of the first application active for the preset duration, including: The Push client sends a first request to the process resource management service, the first request being used to instruct the process resource management service to keep the main process of the first application alive within the preset time period; In response to the first request, the process resource management service keeps the main process of the first application alive for the preset duration.

5. The method according to claim 4, characterized in that, The Push client sends a first request to the process resource management service, including: The Push client sends a first keep-alive request to the process resource management service, the first keep-alive request being used to instruct the process resource management service to keep the main process of the first application alive; At the time when the preset duration is met, the Push client sends a first freeze request to the process resource management service. The first freeze request is used to instruct the process resource management service to freeze the main process of the first application. In response to the first request, the process resource management service keeps the main process of the first application active for a preset period of time, including: In response to the first keep-alive request and the first freeze request, the process resource management service keeps the main process of the first application alive for the preset duration.

6. The method according to claim 2, characterized in that, The terminal device includes a Push client, a process resource management service, and a VoIP management service. The Push client is used to transmit call messages, the process resource management service is used to keep the main process of the first application alive and freeze it, and the VoIP management service is used to receive incoming call notifications. In response to the first call message, if the first application executes the first call notification within the preset time period, the terminal device continues to keep the main process of the first application active after the preset time period, including: The Push client sends a first keep-alive request to the process resource management service, the first keep-alive request being used to instruct the process resource management service to keep the main process of the first application alive; In response to the first keep-alive request, the process resource management service keeps the main process of the first application alive; In response to the first call message, the first application sends the first call notification to the VoIP management service within the preset duration. In response to the first incoming call notification, the VoIP management service sends a second keep-alive request to the process resource management service, the second keep-alive request being used to instruct the process resource management service to keep the main process of the first application alive; At the time when the preset duration is met, the Push client sends a first freeze request to the process resource management service. The first freeze request is used to instruct the process resource management service to freeze the main process of the first application. In response to the second keep-alive request and the first freeze request, the process resource management service continues to keep the main process of the first application alive within the preset time period and after the preset time period.

7. The method according to claim 6, characterized in that, The terminal device also includes a notification display service, which is used to display incoming call notification messages from the first application; After the first application responds to the first call message and sends the first call notification to the VoIP management service within the preset time period, the method further includes: In response to the first incoming call notification, the VoIP management service sends the first incoming call notification message of the first application to the notification display service; The notification display service displays the first incoming call notification message on the terminal device.

8. The method according to claim 7, characterized in that, The method further includes: When the first application is running in the foreground of the terminal device, the first application responds to the second call message received through the long connection and performs a second call notification to the VoIP management service. In response to the second incoming call notification, the VoIP management service sends the second incoming call notification message of the first application to the notification display service; The notification display service displays the second incoming call notification message on the terminal device.

9. The method according to claim 7 or 8, characterized in that, The first incoming call notification message has the same format as the second incoming call notification message.

10. The method according to claim 9, characterized in that, The first and second incoming call notification messages are not displayed in full screen, and both the first and second incoming call notification messages include caller information, an answer button, and a reject button.

11. The method according to claim 10, characterized in that, The first incoming call notification message is displayed on the lock screen interface of the terminal device where a lock screen password is set, and the first incoming call notification message allows the user to answer the incoming call from the first application without unlocking the terminal device.

12. The method according to any one of claims 7-11, characterized in that, The method further includes: The notification display service displays a reminder message in the status bar of the terminal device. The reminder message is used to remind that the call type corresponding to the first incoming call notification message is a VoIP call.

13. A method for making a call, characterized in that, Applied to a terminal device, wherein the terminal device has a first application with VoIP calling functionality installed, the method includes: The terminal device displays a first interface, which is a lock screen interface with a lock screen password. The first interface displays a first incoming call notification message from the first application. The first incoming call notification message occupies a portion of the first interface and includes a first answer button. The terminal device receives a trigger operation on the first answer button; In response to the triggering operation, without unlocking the terminal device, the terminal device connects to the first VoIP call corresponding to the first incoming call notification message.

14. The method according to claim 13, characterized in that, The first incoming call notification message is either a voice call notification message or a video call notification message, and the first VoIP call is a voice call.

15. The method according to claim 13, characterized in that, The first incoming call notification message is a video incoming call notification message, and the first incoming call notification message also includes a second answer button; the method further includes: The terminal device receives a trigger operation on the second answer button; In response to the triggering of the second answer button, the terminal device prompts the user to unlock the terminal device; If the terminal device is successfully unlocked, the terminal device connects to the second VoIP call corresponding to the first incoming call notification message, and the second VoIP call is a video call.

16. The method according to any one of claims 13-15, characterized in that, After the terminal device connects the first VoIP call corresponding to the first incoming call notification message, the method further includes: The terminal device receives an unlocking operation on the terminal device; In response to the unlocking operation, the terminal device displays a second interface and a first reminder message. The second interface is the last interface displayed before the terminal device locks its screen. The first reminder message is located in the status bar and is used to remind users that the incoming call type of the first VoIP call is a VoIP call and / or the progress of the first VoIP call.

17. The method according to claim 16, characterized in that, After the terminal device displays the second interface and the first reminder message, the method further includes: The terminal device receives a trigger operation on the first reminder message; In response to the triggering operation, the terminal device displays a third interface and the first reminder message, wherein the third interface is a full-screen voice call interface.

18. The method according to any one of claims 13-17, characterized in that, After the terminal device connects the first VoIP call corresponding to the first incoming call notification message, the method further includes: The terminal device receives a trigger operation on the first incoming call notification message; In response to the triggering operation of the first incoming call notification message, the terminal device reminds the user to unlock the terminal device; When the terminal device is successfully unlocked, the terminal device displays a third interface and a first reminder message. The third interface is a full-screen voice call interface, and the first reminder message is located in the status bar. The first reminder message is used to remind that the incoming call type of the first VoIP call is a VoIP call, and / or the progress of the first VoIP call.

19. The method according to any one of claims 13-18, characterized in that, The method further includes: The terminal device displays a fourth interface, which is the running interface of the first application. The fourth interface displays a second incoming call notification message from the first application, which is displayed in the notification center.

20. A terminal device, characterized in that, include: A processor, a display screen, and a memory, wherein the memory and the display screen are coupled to the processor, the memory is used to store program code, the program code including instructions, and the processor reads the instructions from the memory to cause the terminal device to perform the method as described in any one of claims 1-12, or to cause the terminal device to perform the method as described in any one of claims 13-19.

21. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a computer program that, when run on a terminal device, causes the terminal device to perform the method as described in any one of claims 1-12, or causes the terminal device to perform the method as described in any one of claims 13-19.

22. A computer program product, characterized in that, The computer program product includes: a computer program or instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-12, or cause the computer to perform the method as described in any one of claims 13-19.

Images