A message pushing method, related apparatus, device, and storage medium
By automatically identifying the scenario type on the terminal and pushing messages when the user's preferences are met, the problem of tedious manual operation and accidental operation in specific scenarios is solved, thus simplifying operation and improving user experience.
Patent Information
- Application Number
- CN202411814695.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-09
- Publication Date
- 2026-06-09
AI Technical Summary
In specific scenarios such as online meetings, users need to manually turn off or on message push notifications from multiple friends and groups, which is cumbersome and prone to errors. Existing technologies cannot effectively simplify this process.
When the Do Not Disturb mode is activated, the device automatically identifies the current scenario type and pushes messages if the preferred settings are met. This includes scenarios such as meetings, screen sharing, media playback, and voice capture. The device determines whether to push messages based on scenario recognition and preferred settings.
It simplifies user operations, avoids accidental operations, meets users' differentiated message push needs in specific scenarios, and improves user experience.
Smart Images

Figure CN122179411A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Internet technology, and in particular to a method, related apparatus, device, and storage medium for push notifications. Background Technology
[0002] With the discovery of the internet, instant messaging (IM) applications have become an indispensable part of people's lives. IM applications can greatly improve the efficiency of communication between people. As people use IM applications to communicate more and more frequently, they also receive IM messages more and more frequently.
[0003] In some scenarios, people may only want to be notified of a few specific messages, while avoiding being bothered by messages they are not interested in. For example, during online meetings, users do not want to be disturbed by received instant messaging messages. In related technologies, users can disable push notifications for specific friends or groups; however, the inventors have found that current solutions have at least the following problems: For instance, during online meetings, users may only want to be notified of a few messages, requiring them to disable push notifications for all other friends and groups individually. After the meeting, they also need to re-enable push notifications for all friends and groups. Clearly, this becomes cumbersome and prone to errors when dealing with a large number of friends and groups. Therefore, an effective method is urgently needed to solve these problems. Summary of the Invention
[0004] This application provides a message push method, related apparatus, device, and storage medium. When the terminal is in message do-not-disturb mode, it pushes messages that meet the preference settings obtained in specific scenario types, thereby simplifying user operations and avoiding accidental operations.
[0005] In view of this, this application provides a method for push notifications, including:
[0006] When the message do-not-disturb mode is enabled, the scene recognition result is obtained, where the scene recognition result indicates the scene type currently corresponding to the terminal;
[0007] If the scene recognition result matches any of the preset scene types in the preset scene type set, then the message to be pushed will be pushed if the message to be pushed meets the preference settings. The preset scene type set includes at least one of the following: meeting scene type, screen sharing scene type, media playback scene type, and voice acquisition scene type.
[0008] This application also provides a message push device, including:
[0009] The acquisition module is used to acquire scene recognition results when the message do-not-disturb mode is activated. The scene recognition results indicate the scene type currently corresponding to the terminal.
[0010] The push module is used to push the message to be pushed if the scene recognition result matches any preset scene type in the preset scene type set, provided that the message to be pushed meets the preference settings. The preset scene type set includes at least one of the following: meeting scene type, screen sharing scene type, media playback scene type, and voice acquisition scene type.
[0011] In one possible design, in another implementation of another aspect of the embodiments of this application,
[0012] The acquisition module is specifically used to acquire audio capture results when the message do-not-disturb mode is activated;
[0013] If the audio capture result indicates the existence of an audio capture identifier belonging to another application, then obtain the current volume mode of the terminal. Here, other applications are applications other than the target application, and the audio capture identifier is used to indicate the audio capture request triggered by the application.
[0014] If the volume mode is call volume mode, then the scene recognition result is determined to be a conference scene type.
[0015] In one possible design, in another implementation of another aspect of the embodiments of this application,
[0016] The acquisition module is specifically used to acquire the running status information of the target application when the message do-not-disturb mode is enabled;
[0017] If the running status information indicates that the target application is running a voice acquisition service, the scene recognition result is determined to be a voice acquisition scene type.
[0018] In one possible design, in another implementation of another aspect of the embodiments of this application,
[0019] The acquisition module is specifically used to detect screen recording events when the message do-not-disturb mode is enabled;
[0020] If a start notification for a screen recording event is detected, the scene identification result is determined to be a screen sharing scene type.
[0021] In one possible design, in another implementation of another aspect of the embodiments of this application,
[0022] The acquisition module is specifically used to acquire audio playback results when the message do-not-disturb mode is activated;
[0023] If the audio playback result indicates that there is an audio playback identifier belonging to another application, then obtain the current volume mode and playback duration of the terminal. Here, other applications are applications other than the target application, and the audio playback identifier is used to indicate the audio playback request triggered by the application.
[0024] If the volume mode is media volume mode and the playback duration is greater than or equal to the duration threshold, then the scene recognition result is determined to be a media playback scene type.
[0025] In one possible design, in another implementation of another aspect of the embodiments of this application,
[0026] The acquisition module is specifically used to acquire the running status information of the target application when the message do-not-disturb mode is enabled;
[0027] If the running status information indicates that the target application is running a media playback service, the scene identification result is determined to be a media playback scene type.
[0028] In one possible design, in another implementation of another aspect of the embodiments of this application, the message push device further includes a display module;
[0029] The display module is used to display K scene type options, where each scene type option corresponds to a preset scene type, and K is an integer greater than 1;
[0030] The acquisition module is also configured to, in response to a selection operation for at least one of the K scene type options, acquire a preset scene type set, wherein the preset scene type set includes a preset scene type corresponding to each of the at least one scene type options.
[0031] In one possible design, in another implementation of another aspect of the embodiments of this application, the message push device further includes a determining module;
[0032] The acquisition module is also used to acquire the message push time corresponding to the message to be pushed;
[0033] The determination module is used to determine whether the message to be pushed meets the preference settings if the message push time is within the non-push time range.
[0034] The determination module is also used to determine if the message to be pushed does not meet the preference settings if the message push time is not within the non-push time range.
[0035] In one possible design, in another implementation of another aspect of the embodiments of this application, the message push device further includes a construction module;
[0036] The acquisition module is also used to acquire the target start time in response to a setting operation for the start time;
[0037] The acquisition module is also used to acquire the target end time in response to a setting operation for the end time;
[0038] The building module is used to construct the non-push time range based on the target start time and target end time.
[0039] In one possible design, in another implementation of another aspect of the embodiments of this application,
[0040] The acquisition module is also used to acquire the target session identifier corresponding to the message to be pushed, wherein the target session identifier is used to indicate the session to which the message to be pushed belongs;
[0041] The determination module is also used to determine that if the target session identifier matches any session identifier in the preset session identifier set, the message to be pushed meets the preference setting conditions.
[0042] The determination module is also used to determine that the message to be pushed does not meet the preference settings if the target session identifier fails to match all session identifiers in the preset session identifier set.
[0043] In one possible design, in another implementation of another aspect of the embodiments of this application,
[0044] The determination module is also used to determine if the message to be pushed meets the preference setting conditions if the message content corresponding to the message to be pushed contains a keyword from the preset keyword set;
[0045] The determination module is also used to determine that the message to be pushed does not meet the preference settings if the message content corresponding to the message to be pushed does not contain any keywords from the preset keyword set.
[0046] In one possible design, in another implementation of another aspect of the embodiments of this application,
[0047] The acquisition module is also used to acquire the target message type corresponding to the message to be pushed;
[0048] The determination module is also used to determine that if the target message type matches any message type in the preset message type set, the message to be pushed meets the preference setting conditions.
[0049] The determination module is also used to determine that the message to be pushed does not meet the preference settings if the target message type fails to match any message type in the preset message type set.
[0050] In one possible design, in another implementation of another aspect of the embodiments of this application,
[0051] The acquisition module is also used to acquire the target source identifier corresponding to the message to be pushed, wherein the target source identifier is used to indicate the message source of the message to be pushed;
[0052] The determination module is also used to determine that if the target source identifier matches any source identifier in the preset source identifier set, the message to be pushed meets the preference setting conditions.
[0053] The determination module is also used to determine that the message to be pushed does not meet the preference settings if the target source identifier fails to match all source identifiers in the preset source identifier set.
[0054] In another aspect, this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods described above.
[0055] Another aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the methods described above.
[0056] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods described above.
[0057] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:
[0058] This application provides a message push method. When the message do-not-disturb mode is activated, a scene recognition result is obtained. Based on this, if the scene recognition result matches any preset scene type in a preset scene type set, the message to be pushed is pushed if it meets the preference settings. Through this method, when the message do-not-disturb mode is activated, the terminal can automatically identify the current scene type and further judge the message to be pushed received in a specific scene type. That is, if the message to be pushed meets the preference settings, it is automatically pushed, thereby simplifying user operation and avoiding accidental operation. Attached Figure Description
[0059] Figure 1 This is a schematic diagram illustrating an application message notification in an embodiment of this application;
[0060] Figure 2 This is a schematic diagram illustrating an application of instant messaging message notification in an embodiment of this application;
[0061] Figure 3 This is a schematic diagram illustrating the application of native message notification in an embodiment of this application;
[0062] Figure 4 This is a schematic diagram of an implementation environment for the message push method in this application embodiment;
[0063] Figure 5 This is a flowchart illustrating the message push method in an embodiment of this application;
[0064] Figure 6 This is a schematic diagram illustrating the setting of a preset scene type in an embodiment of this application;
[0065] Figure 7 This is a schematic diagram illustrating the setting of a non-push time range in an embodiment of this application;
[0066] Figure 8 This is a schematic diagram of an interface for setting a preference session in an embodiment of this application;
[0067] Figure 9 This is a schematic diagram of a process for identifying push messages in an embodiment of this application;
[0068] Figure 10 This is a schematic diagram of an interface for setting preference keywords in an embodiment of this application;
[0069] Figure 11 This is another flowchart illustrating the process of identifying the push message in this application embodiment;
[0070] Figure 12 This is a schematic diagram of an interface for setting message types in an embodiment of this application;
[0071] Figure 13 This is another flowchart illustrating the process of identifying the push message in this application embodiment;
[0072] Figure 14 This is a schematic diagram of an interface for setting the message source in an embodiment of this application;
[0073] Figure 15 This is a schematic diagram of the architecture of the message push system in an embodiment of this application;
[0074] Figure 16 This is a schematic diagram of a message push device in an embodiment of this application;
[0075] Figure 17 This is a schematic diagram of the structure of a terminal in an embodiment of this application. Detailed Implementation
[0076] This application provides a message push method, related apparatus, device, and storage medium. When the terminal is in message do-not-disturb mode, it pushes messages that meet the preference settings obtained in specific scenario types, thereby simplifying user operations and avoiding accidental operations.
[0077] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “corresponding,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0078] In today's information society, messaging has become an indispensable communication tool for terminals. As people receive messages more frequently, this also means they are being bombarded with push notifications more often. However, in some scenarios (such as meetings), people may only want to receive notifications of messages they are interested in, without being disturbed by other messages. Therefore, users can pre-set which messages should be pushed to them and which should not, according to their needs. However, in reality, users receive many messages from various sources, and setting these individually is not only time-consuming but also prone to errors. Forgetting to switch certain messages to pushable status may also cause users to miss important messages.
[0079] Based on this, this application provides a message push method that, with simple operation, satisfies the user's need to receive only messages of interest without being disturbed by other messages. This not only simplifies user operation but also enriches usage scenarios, thereby improving the user experience.
[0080] Before introducing the specific methods of this application, the application scenarios of this application will be illustrated by example. It should be understood that the following application scenarios are merely illustrative and are not limited to these examples.
[0081] I. Application message notification scenarios;
[0082] Terminals (such as mobile phones, tablets, etc.) can support the installation of various types of applications (APPs), which can push notification messages to the terminal. When the terminal receives a notification message from an APP, it can display the notification message in the notification bar or directly pop up a message prompt box, etc.
[0083] Users may want to receive notifications only from certain app push notifications during meetings. For example, please refer to [link to example]. Figure 1 , Figure 1 This is a schematic diagram illustrating an application message notification in an embodiment of this application, such as... Figure 1 As shown in Figure (A), users can configure which apps' messages can be pushed to them during a meeting. 101 indicates the settings control for app A; by enabling push notifications for app A, users can send relevant messages from app A during the meeting. Figure 1 As shown in Figure (B), 102 is used to indicate a notification message for application A, that is, in a meeting scenario, the terminal will push a notification message about application A.
[0084] II. IM message notification scenarios;
[0085] When a terminal receives a new IM message, it will be pushed to the user through the IM application. IM messages include, but are not limited to, text, voice, video, images, audio, and files; in other words, the IM application provides the ability to send and receive messages instantly.
[0086] Users may want to receive notifications only from select friends during meetings. For example, please refer to [link to example]. Figure 2 , Figure 2 This is a schematic diagram illustrating an application of instant messaging notifications in an embodiment of this application, such as... Figure 2 As shown in Figure (A), users can configure which friends or groups' messages can be pushed to them during a meeting. 201 indicates the settings control for friend B; by enabling the message push function for friend B, users can push relevant messages from friend B during the meeting. Figure 2 As shown in Figure (B), 202 is used to indicate a notification message sent by friend B. That is, in a meeting scenario, the terminal will push an IM message about friend B.
[0087] III. Native message notification scenarios;
[0088] Native messages can be system notifications, such as system upgrade messages and system alarm messages, or system communication messages, such as incoming call messages and SMS messages. Users can view native messages in the device's notification center or on the lock screen.
[0089] Users may want to receive notifications only for messages sent to select contacts during meetings. For example, please refer to [link to example]. Figure 3 , Figure 3 This is a schematic diagram of an application of native message notification in an embodiment of this application, such as... Figure 3 As shown in Figure (A), users can configure which contacts' SMS or call messages can be pushed to them during a meeting. 301 indicates the call settings and SMS settings controls for user C. By enabling the call message push function for user C, users can receive push notifications for calls from user C during the meeting. Figure 3 As shown in Figure (B), 302 is used to indicate the incoming call message of user C. That is, in a conference scenario, the terminal will push an incoming call message about user C.
[0090] It should be noted that the above application scenarios are merely examples, and the message push method provided in this embodiment can also be applied to other scenarios, which are not limited here.
[0091] The method provided in this application can be applied to... Figure 4 The illustrated implementation environment includes a terminal 401 and a server 402, and the terminal 401 and server 402 can communicate with each other via a communication network 403. The communication network 403 uses standard communication technologies and / or protocols, typically the Internet, but can also be any network, including but not limited to Bluetooth, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), mobile, private networks, or any combination of virtual private networks. In some embodiments, customized or dedicated data communication technologies may be used to replace or supplement the aforementioned data communication technologies.
[0092] The terminal 401 involved in this application includes a human-computer interaction screen, a processor, and a memory. The human-computer interaction screen displays the interface and provides a human-computer interaction interface: terminal 401 includes, but is not limited to, mobile phones, tablets, laptops, desktop computers, intelligent voice interaction devices, virtual reality devices, smart home appliances, vehicle terminals, aircraft, etc. The client is deployed on terminal 401 and can run on terminal 401 through a browser, or through a standalone APP or mini-program, etc.
[0093] The server 402 involved in this application can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence (AI) platforms.
[0094] In the above implementation environment, in step A1, when terminal 401 activates the message do-not-disturb mode, the scene recognition result is obtained. In step A2, server 402 sends the message to be pushed to terminal 401 through communication network 403. In step A3, if the scene recognition result matches any preset scene type in the preset scene type set, then terminal 401 pushes the message to be pushed if the message meets the preference settings.
[0095] Based on the above introduction, the message push method in this application will be described below. Please refer to [link / reference]. Figure 5 In this application, the message push method can be completed independently by the terminal or in cooperation with the server. The method provided in this application includes:
[0096] S501. When the message do-not-disturb mode is activated, obtain the scene recognition result, wherein the scene recognition result indicates the scene type currently corresponding to the terminal;
[0097] In one or more embodiments, the terminal enables a message do-not-disturb mode, wherein the message do-not-disturb mode means that the terminal does not push received messages by default.
[0098] Specifically, one implementation involves the terminal periodically performing scene recognition, for example, every 10 seconds. Based on this, when the terminal receives a message to be pushed, it uses the most recently identified scene type as the scene recognition result. Another implementation involves the terminal performing scene recognition when it receives a message, thereby obtaining the scene recognition result.
[0099] S502. If the scene recognition result matches any preset scene type in the preset scene type set, then the message to be pushed is pushed if the message to be pushed meets the preference setting conditions. The preset scene type set includes at least one of the following: meeting scene type, screen sharing scene type, media playback scene type, and voice acquisition scene type.
[0100] In one or more embodiments, the user can set a preset set of scene types. If the scene recognition result successfully matches a preset scene type, the user can further determine whether the message to be pushed meets the preference settings. If the message to be pushed meets the preference settings, the message is pushed. The message to be pushed can be a message sent from the server to the terminal (e.g., an IM message, a system upgrade message, etc.) or a message generated locally on the terminal (e.g., a game message, an alarm message, etc.).
[0101] Specifically, assume the preset scenario type set includes meeting scenario type, screen sharing scenario type, media playback scenario type, and voice acquisition scenario type. Taking "meeting scenario type" as an example, it can be seen that the scenario recognition result successfully matches "meeting scenario type" in the preset scenario type set. Therefore, it is determined whether the message to be pushed meets the preference settings. Meeting the preference settings includes, but is not limited to, at least one of the following: a message received within a specific time period; a message sent by a specific object (e.g., a message sent by friend A, a message sent by group 1); a message containing keywords; or a message belonging to a specific message type (e.g., voice, video, a file in a specific format, etc.).
[0102] If the message to be pushed meets the preference settings, the message will be pushed. It is worth noting that in this application, "push" includes at least one of the following: pushing a message, reminding a user of a message (e.g., indicating a new message has arrived in the app with a red dot icon), and pushing and reminding a user of a message. Specifically, at least one of the following methods can be used for pushing: for example, displaying the message to be pushed in the notification bar, i.e., displaying part or all of the content of the message to be pushed; another example, playing a notification sound when a new message arrives, i.e., the user can customize the notification sound or choose the default notification sound to remind a user of the message; another example, reminding a user through vibration, i.e., the user can adjust the vibration intensity, duration, and rhythm to set the message push method; another example, prioritizing the message to be pushed so that the user can see the message to be pushed first after receiving a message notification.
[0103] It should be noted that if the scene recognition result does not match any of the preset scene types in the preset scene type set, the terminal will not push the message to be pushed. Similarly, if the message to be pushed does not meet the preference settings, the terminal will also not push the message. In this case, the terminal can save the message to be pushed to the unread message list so that the user can view it later.
[0104] This application provides a message push method. Through this method, when the terminal is in Do Not Disturb mode, it can automatically identify the current scenario type and further judge the messages to be pushed in that specific scenario. That is, if the message to be pushed meets the preference settings, it will be automatically pushed, thereby simplifying user operations and avoiding accidental operations.
[0105] Optionally, in the above Figure 5 Based on one or more corresponding embodiments, in another optional embodiment provided by this application, when the message do-not-disturb mode is activated, obtaining the scene recognition result may specifically include:
[0106] Obtain audio capture results while the message do-not-disturb mode is enabled;
[0107] If the audio capture result indicates the existence of an audio capture identifier belonging to another application, then obtain the current volume mode of the terminal. Here, other applications are applications other than the target application, and the audio capture identifier is used to indicate the audio capture request triggered by the application.
[0108] If the volume mode is call volume mode, then the scene recognition result is determined to be a conference scene type.
[0109] In one or more embodiments, a method for identifying meeting scenario types is described. As can be seen from the foregoing embodiments, in a meeting scenario, users typically wish to avoid being disturbed by unimportant messages. Therefore, the terminal can activate a message do-not-disturb mode, that is, unimportant messages will not be pushed during a meeting. Meeting scenarios include, but are not limited to, voice conferences and video conferences. Since the application conducting the meeting and the target application (e.g., an IM application) may not belong to the same application, indirect means can be used to identify whether a meeting scenario is in progress.
[0110] Since meetings often involve voice calls, an application programming interface (API) can be used to capture audio. To further enhance voice quality, the API can also be used to adjust call volume. The captured data is then processed by the system's hardware 3A (acoustic echo cancellation, AEC, automatic noise suppression, ANS, and automatic gain control) to achieve better call quality. Therefore, the meeting scenario can be indirectly identified by sensing audio capture markers and volume patterns.
[0111] The following example will be used, where the message to be pushed comes from an IM application (i.e., the target APP is an IM application) and the terminal uses the Android system.
[0112] Specifically, when the IM application is launched, it can register with the Android system to receive notifications related to audio capture, for example, it can register using the following method:
[0113] public void registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb,
[0114] Handler handler)
[0115] As can be seen, the terminal calls the "registerAudioRecordingCallback" method to register an audio capture callback function. This function is used to receive system notifications about audio capture activities. That is, when another application in the Android system initiates audio capture, the IM application can receive a notification. The notification carries the audio capture identifier corresponding to all audio capture requests. This audio capture identifier is a unique identifier used to distinguish audio capture requests triggered by different apps. For example, multiple apps may perform audio capture simultaneously, and each app's audio capture request will be assigned a unique identifier.
[0116] For example, suppose the notification received by the IM application carries audio capture identifiers "1" and "2". The IM application itself also initiates an audio capture request, with the corresponding audio capture identifier being "2". Therefore, an audio capture identifier of "1" corresponds to an audio capture request initiated by another app, meaning it can be determined that the user is still using another app to record audio.
[0117] Based on this, the current volume mode of the terminal can be obtained in the following way:
[0118] public int getMode()
[0119] A return value of "0" indicates media volume mode (MODE_NORMAL). A return value of "1" indicates ringtone volume mode (MODE_RINGTONE). A return value of "2" indicates system phone mode (MODE_IN_CALL). A return value of "3" indicates call volume mode (MODE_IN_COMMUNICATION).
[0120] As can be seen, when the return value is "3", it can be inferred that the user is using the collected audio for a voice call, and the scene recognition result is considered to be a meeting scene. In a meeting scene, the terminal will push messages based on user preferences.
[0121] It's worth noting that the terminal can further verify whether it's in a meeting scenario by using data collected by sensors or system status. For example, it can determine if the terminal has its camera activated; if so, it indicates that the terminal may be conducting a video call. Furthermore, considering that meeting scenarios often have a high degree of real-time requirement—that is, data needs to be continuously received and sent (i.e., voice data, video data, file data, etc.)—data transmission often consumes more bandwidth. Based on this, it can be determined whether the terminal's bandwidth consumption over a period of time exceeds a bandwidth threshold. If so, it indicates that the terminal is using a significant amount of bandwidth for data transmission over that period, suggesting that the terminal may be conducting an audio call, video call, or transferring files.
[0122] Secondly, this application provides a method for identifying meeting scenario types. Using this method, the terminal can identify whether it is currently in a meeting scenario by calling a specific method. In a meeting scenario, the terminal pushes messages that the user is interested in based on the user's needs. This satisfies the user's differentiated message push needs in meeting scenarios, eliminating the need for frequent manual switching of message push settings, avoiding frequent message interruptions, and thus improving the user experience.
[0123] Optionally, in the above Figure 5 Based on one or more corresponding embodiments, in another optional embodiment provided by this application, when the message do-not-disturb mode is activated, obtaining the scene recognition result may specifically include:
[0124] When the Do Not Disturb mode is enabled, obtain the running status information of the target application;
[0125] If the running status information indicates that the target application is running a voice acquisition service, the scene recognition result is determined to be a voice acquisition scene type.
[0126] In one or more embodiments, a method for identifying voice acquisition scenario types is described. As can be seen from the foregoing embodiments, in voice acquisition scenarios, users often need to concentrate on voice acquisition. Therefore, users typically want to avoid being disturbed by unimportant messages while acquiring voice. Based on this, the terminal can activate a message do-not-disturb mode, that is, unimportant messages will not be pushed during voice acquisition scenarios. Voice acquisition scenarios include, but are not limited to, acquiring users' voice messages, recording users' singing audio, and conducting real-time calls with other users. Since the application performing voice acquisition and the target application (e.g., an IM application) may belong to the same application, it is possible to directly identify whether a voice acquisition scenario is in progress.
[0127] Specifically, the target application can directly obtain the current running status information, which includes at least one service identifier. Each service identifier indicates the type of service the target application is running. For easier understanding, please refer to Table 1, which illustrates the relationship between service identifiers and service types.
[0128] Table 1
[0129] Business Identifier Business type 0 Default services (e.g., session services) 1 Voice recording service 2 Video playback service 3 Audio playback service 4 Payment services 5 Online meeting services
[0130] Therefore, if the running status information includes at least one of the service identifiers "1" and "5", it indicates that the target application is running a service related to voice acquisition. Thus, the scene recognition result can be determined as a voice acquisition scene type. Voice acquisition services include, but are not limited to, voice recording services and online conferencing services.
[0131] Secondly, this application provides a method for identifying voice acquisition scenario types. This method takes into account that the target application can not only receive messages but also potentially perform voice acquisition-related services. Therefore, the target application directly determines whether it is in a voice acquisition scenario based on its current operating status information. This satisfies users' differentiated needs for message push notifications in voice acquisition scenarios, eliminates the need for frequent manual switching of message push settings, and avoids users being frequently disturbed by messages, thereby improving the user experience.
[0132] Optionally, in the above Figure 5 Based on one or more corresponding embodiments, in another optional embodiment provided by this application, when the message do-not-disturb mode is activated, obtaining the scene recognition result may specifically include:
[0133] Detect screen recording events when Do Not Disturb mode is enabled;
[0134] If a start notification for a screen recording event is detected, the scene identification result is determined to be a screen sharing scene type.
[0135] In one or more embodiments, a method for identifying screen sharing scenario types is described. As can be seen from the foregoing embodiments, frequent message pushes in screen sharing scenarios not only disturb users but also easily leak user privacy. Therefore, the terminal can activate a message do-not-disturb mode, that is, not pushing unimportant messages in screen sharing scenarios. Since the application performing screen sharing and the target application (e.g., an IM application) may not belong to the same application, indirect means can be used to identify whether screen sharing is in progress.
[0136] It's understandable that screen sharing is essentially screen recording; it's sending the recorded data to a remote user without saving it. Therefore, screen sharing can be indirectly detected by detecting screen recording, and the system provides corresponding channels for detecting screen recording.
[0137] The following example will be based on the scenario where the message to be pushed originates from an IM application and the terminal uses the Android system.
[0138] Specifically, when an IM application is launched, the terminal can use the following methods to detect screen recording:
[0139] public void registerCallback(MediaProjection.Callback callback,
[0140] Handler handler)
[0141] The terminal calls the `registerCallback` method to register a callback detector for screen recording events, used to receive notifications about changes in the screen recording status. If a start notification for a screen recording event is detected via the `onCapturedContentVisibilityChanged` method, it indicates that screen recording has begun, i.e., screen sharing has begun. If a stop notification for a screen recording event is detected via the `onStop` method, it indicates that screen recording has ended, i.e., screen sharing has ended. Based on this, if a start notification is detected, it means that screen sharing is currently in progress, and the scene identification result is considered a screen sharing scenario. In a screen sharing scenario, the terminal will push messages based on user preferences.
[0142] Secondly, this application provides a method for identifying screen sharing scenario types. Through this method, the terminal can identify whether it is currently in a screen sharing scenario by calling a specific method. In a screen sharing scenario, the terminal pushes messages that the user is interested in based on the user's needs. This satisfies the user's differentiated needs for message pushes in screen sharing scenarios, eliminates the need for frequent manual switching of message push settings, and avoids the user being frequently disturbed by messages, thereby improving the user experience.
[0143] Optionally, in the above Figure 5 Based on one or more corresponding embodiments, in another optional embodiment provided by this application, when the message do-not-disturb mode is activated, obtaining the scene recognition result may specifically include:
[0144] Obtain audio playback results while the Do Not Disturb mode is enabled;
[0145] If the audio playback result indicates that there is an audio playback identifier belonging to another application, then obtain the current volume mode and playback duration of the terminal. Here, other applications are applications other than the target application, and the audio playback identifier is used to indicate the audio playback request triggered by the application.
[0146] If the volume mode is media volume mode and the playback duration is greater than or equal to the duration threshold, then the scene recognition result is determined to be a media playback scene type.
[0147] In one or more embodiments, a method for identifying media playback scenario types is described. As can be seen from the foregoing embodiments, frequent message pushes during media playback can negatively impact user experience. Therefore, the terminal can activate a message do-not-disturb mode, meaning that non-important messages will not be pushed during media playback. Media playback scenarios include, but are not limited to, playing music and videos. Since the application playing daily and the target application (e.g., an IM application) may not belong to the same application, indirect means can be used to identify whether a meeting scenario is in progress.
[0148] Since media playback scenarios mainly involve playing audio or video, they all involve playing sound. The volume mode in a media playback scenario should be the media volume mode. Therefore, the playback status and media volume mode of non-target applications can be used as the basis for identifying media playback scenarios.
[0149] The following example will be based on the scenario where the message to be pushed originates from an IM application (i.e., the target APP is an IM application) and the terminal uses the Android system.
[0150] Specifically, when the IM application is launched, it can register with the Android system for playback-related notifications to detect changes in audio playback. For example, it can be registered using the following method:
[0151] public void registerAudioPlaybackCallback(AudioManager.AudioPlaybackCallback cb,
[0152] Handler handler)
[0153] As can be seen, the terminal calls the "registerAudioPlaybackCallback" method to register an audio playback callback function. This function is used to receive system notifications about audio playback activities. That is, when another application in the Android system initiates audio playback, the IM application can receive a notification. The notification carries the audio playback identifier corresponding to all audio playback requests. This audio playback identifier is a unique identifier used to distinguish audio playback requests triggered by different apps. For example, multiple apps may play audio simultaneously, and each app's audio playback request will be assigned a unique identifier.
[0154] For example, suppose the notification received by the IM application carries audio playback identifiers "5" and "8". The IM application itself also initiates an audio playback request, with the corresponding audio playback identifier being "8". Therefore, the audio playback identifier "5" corresponds to an audio playback request initiated by another app, meaning it can be determined that the user is still using another app for audio playback.
[0155] Based on this, the current volume mode of the terminal can be obtained in the following way:
[0156] public int getMode()
[0157] In this scenario, a return value of "0" indicates that the terminal is currently in media volume mode. Therefore, the terminal can calculate the playback duration based on playback event notifications. If the playback duration is greater than or equal to a duration threshold (e.g., 10 seconds), the scene identification result is determined to be a media playback scene, thus eliminating interference from brief message ringtones. In the media playback scene, the terminal will push messages based on user preferences.
[0158] It should be noted that the terminal can further verify whether it is in a media playback scenario by using data collected by sensors or system status. For example, it can determine whether the terminal's screen is continuously lit; if the screen is continuously lit, it indicates that the terminal may be playing a video. Another example is determining whether the terminal's network traffic consumption is high; if the consumption is high, it indicates that the terminal may be using data to download multimedia data.
[0159] Secondly, this application provides a method for identifying media playback scenario types. Through this method, the terminal can identify whether it is currently in a media playback scenario by calling a specific method. In a media playback scenario, the terminal pushes messages that the user is interested in based on the user's needs. This satisfies the user's differentiated needs for message pushes in media playback scenarios, eliminates the need for frequent manual switching of message push settings, and avoids the user being frequently disturbed by messages, thereby improving the user experience.
[0160] Optionally, in the above Figure 5 Based on one or more corresponding embodiments, in another optional embodiment provided by this application, when the message do-not-disturb mode is activated, obtaining the scene recognition result may specifically include:
[0161] When the Do Not Disturb mode is enabled, obtain the running status information of the target application;
[0162] If the running status information indicates that the target application is running a media playback service, the scene identification result is determined to be a media playback scene type.
[0163] In one or more embodiments, another method for identifying media playback scenario types is introduced. As can be seen from the foregoing embodiments, frequent message pushes in a media playback scenario can negatively impact user experience. Therefore, the terminal can activate a message do-not-disturb mode, i.e., not pushing unimportant messages during media playback. Since the application performing voice capture and the target application (e.g., an IM application) may belong to the same application, it is possible to directly identify whether a media playback scenario is in progress.
[0164] Specifically, the target application can directly obtain its current operational status information, which includes at least one service identifier. Each service identifier indicates the type of service the target application is running. For clarity, please refer to Table 1 again. Based on this, if the operational status information includes at least one of service identifiers "2" and "3", it indicates that the target application is running a service related to a media playback scenario. Therefore, the scenario identification result can be determined as a media playback scenario type. Media playback services include, but are not limited to, audio playback services and video playback services.
[0165] Secondly, this application provides another method for identifying media playback scenario types. This method takes into account that the target application can not only receive messages but also potentially perform media playback-related services. Therefore, the target application directly determines whether it is in a media playback scenario based on its current operating status information. This satisfies users' differentiated needs for message push notifications in media playback scenarios, eliminates the need for frequent manual switching of message push settings, and avoids users being frequently disturbed by messages, thereby improving the user experience.
[0166] Optionally, in the above Figure 5 In addition to one or more corresponding embodiments, another optional embodiment provided in this application may further include:
[0167] Display K scene type options, where each scene type option corresponds to a preset scene type, and K is an integer greater than 1;
[0168] In response to a selection operation for at least one of the K scene type options, a preset scene type set is obtained, wherein the preset scene type set includes the preset scene type corresponding to each of the at least one scene type options.
[0169] In one or more embodiments, a method for supporting users to set preset scene types is described. As can be seen from the foregoing embodiments, users can customize the set of preset scene types, and further, users can also select which apps on the terminal belong to the preset scene types.
[0170] Specifically, for ease of understanding, please refer to Figure 6 , Figure 6 The figure shows a schematic diagram of setting preset scene types in an embodiment of this application. Four scene type options are shown (i.e., K equals 4), each corresponding to a preset scene type. Assuming the user selects the scene type option indicated by 601 and the scene type option indicated by 602, a selection operation for these two scene type options is triggered. Thus, the preset scene type set is determined to include "conference scene type" and "media playback scene type".
[0171] It should be noted that in practical applications, users can also click the selection control indicated by 603 to select one or more apps as preset scene types. Furthermore, users can customize preset scene types according to their needs. For example, a user who frequently uses a certain office software for work may not want to be disturbed by numerous messages while working. Based on this, they can add that office software as a preset scene type. In addition, users can remove one or more preset scene types from the set.
[0172] Furthermore, this application provides a method for supporting users to set preset scene types. Through this method, users can set preset scene types according to their own usage habits, thereby achieving personalized message push functionality. Simultaneously, the terminal will automatically determine whether to push received messages based on the preset scene type set, thus simplifying user operations and improving the user experience.
[0173] Optionally, in the above Figure 5 In addition to one or more corresponding embodiments, another optional embodiment provided in this application may further include:
[0174] Get the message push time corresponding to the message to be pushed;
[0175] If the message push time is outside the push time range, then the message to be pushed is determined to meet the preference settings.
[0176] If the message push time is outside the non-push time range, it is determined that the message to be pushed does not meet the preference settings.
[0177] In one or more embodiments, a method for determining whether preference settings are met is described. As can be seen from the foregoing embodiments, users can set a non-push time range, and only messages received within this non-push time range will be pushed. The following will illustrate this with examples.
[0178] Specifically, let's assume the non-push time range is from 13:00:00 to 18:00:00 daily. Taking a message push time of 14:34:08 as an example, this push time falls within the non-push time range, indicating that the message to be pushed meets the preference settings. Taking a message push time of 22:07:11 as an example, this push time is outside the non-push time range, indicating that the message to be pushed does not meet the preference settings, i.e., the Do Not Disturb mode is used (i.e., no message push is sent).
[0179] For example, if the message to be pushed is a message sent by the server to the terminal, the message push time can be the time when the server sends the message to be pushed. If the message to be pushed is a message generated by the terminal, the message push time can be the time when the terminal generates the message to be pushed. One implementation is to include a timestamp in the message to be pushed. The terminal parses the message to be pushed to obtain the timestamp, thereby determining the corresponding message push time. Another implementation is that the terminal can determine the message push time by calling a clock module. The format of the message push time can be "xxxx year xx month xx day xx hour xx minute xx second".
[0180] Secondly, this application provides a method for determining whether preference settings are met. Using this method, users can set their preferred message push time periods; that is, only messages received outside the push time range will be pushed, while messages received outside the push time range will not notify the user, thus avoiding disturbance to the user.
[0181] Optionally, in the above Figure 5 In addition to one or more corresponding embodiments, another optional embodiment provided in this application may further include:
[0182] In response to a setting operation for the start time, obtain the target start time;
[0183] In response to a setting operation for the end time, obtain the target end time;
[0184] Construct a non-push time range based on the target start time and target end time.
[0185] In one or more embodiments, a method is described that supports users in setting non-push time ranges. As can be seen from the foregoing embodiments, users can customize the non-push time range, and further, users can also set the repetition of non-push time ranges.
[0186] Specifically, for ease of understanding, please refer to Figure 7 , Figure 7 This is a schematic diagram illustrating the setting of a non-push time range in an embodiment of this application, such as... Figure 7 As shown in Figure (A), 701 indicates the setting area for the start time. Users can select a time as the target start time by sliding the timeline, thus completing the start time setting operation. Figure 7 As shown in Figure (B), 702 indicates the setting area for the end time. Users can select a time as the target end time by sliding the timeline, thus completing the end time setting operation. Assuming the target start time is "23:00" and the target end time is "23:40", then the non-push time range is "23:00 to 23:40". Furthermore, users can also set the repetition of the non-push time range, for example, Monday to Friday.
[0187] It should be noted that in practical applications, users can also manually enter the target start time and target end time in the text input box. The target start time and target end time can be accurate to the second; this is not limited here.
[0188] Furthermore, this application provides a method for users to set non-push time ranges. Through this method, users can set non-push time ranges according to their own usage habits, thereby achieving personalized message push functionality. Simultaneously, the terminal will automatically determine whether to push received messages based on the non-push time range, thus simplifying user operations and improving the user experience.
[0189] Optionally, in the above Figure 5 In addition to one or more corresponding embodiments, another optional embodiment provided in this application may further include:
[0190] Obtain the target session identifier corresponding to the message to be pushed, whereby the target session identifier is used to indicate the session to which the message to be pushed belongs;
[0191] If the target session identifier matches any session identifier in the preset session identifier set, then the message to be pushed is determined to meet the preference settings.
[0192] If the target session identifier fails to match any session identifier in the preset session identifier set, it is determined that the message to be pushed does not meet the preference settings.
[0193] In one or more embodiments, another method for determining whether preference settings are met is described. As described in the foregoing embodiments, the message to be pushed can be an IM message, that is, the message to be pushed belongs to a specific session. Users can set at least one preferred session, and the session identifiers corresponding to these sessions are used as a preset session identifier set. If the target session identifier corresponding to the message to be pushed matches a session identifier in the preset session identifier set, then the message to be pushed is determined to meet the preference settings. When a message is received from the preferred session, it is identified as a message that the user is interested in, and the message is pushed.
[0194] Specifically, for ease of understanding, please refer to Figure 8 , Figure 8 The figure shows a schematic diagram of an interface for setting preferred sessions in an embodiment of this application. 801 indicates a session selected by the user (i.e., a session with friend B), and assumes the session identifier corresponding to this session is "2". 802 indicates another session selected by the user (i.e., a session with group 1), and assumes the session identifier corresponding to this session is "3". The preset session identifier set includes session identifier "2" and session identifier "3".
[0195] Assuming the message to be pushed originates from group 1 and its corresponding target session identifier is "3", the target session identifier matches the session identifier "3" in the preset session identifier set, meaning the message to be pushed meets the preference settings. Assuming the message to be pushed originates from group 2 and its corresponding target session identifier is "4", the target session identifier fails to match any session identifier in the preset session identifier set, meaning the message to be pushed does not meet the preference settings.
[0196] It should be noted that users can set different preferred sessions for different scenario types. For example, for a meeting scenario, the preferred sessions can include sessions with Group 1. Similarly, for a screen sharing scenario, the preferred sessions can include sessions with both Group 1 and Friend A.
[0197] Based on this, the following will combine Figure 9 This describes the process of identifying push notification messages. Please refer to [link / reference]. Figure 9 , Figure 9 This is a flowchart illustrating the process of identifying the message to be pushed in an embodiment of this application. As shown in the figure, taking an IM message as an example, the specific steps are as follows:
[0198] In step S901, the terminal receives the push message sent by the server.
[0199] In step S902, the terminal determines the session to which the message to be pushed belongs, for example, the session to which user A belongs.
[0200] In step S903, it is determined whether the terminal is displaying the session to which the message to be pushed belongs. If yes, step S904 is executed; otherwise, step S905 is executed.
[0201] In step S904, when the terminal is displaying the session to which the message to be pushed belongs, the message to be pushed is identified as the target message, that is, the message to be pushed is directly displayed on the session interface.
[0202] In step S905, if the terminal does not display the session to which the message to be pushed belongs, the system determines whether the session to which the message to be pushed belongs to is a preferred session by judging whether the target session identifier corresponding to the message to be pushed matches the preset session identifier set. If yes, step S906 is executed; otherwise, step S907 is executed.
[0203] In step S906, if the session to which the message to be pushed belongs is a preferred session, the message to be pushed is identified as the target message and the message is directly pushed to the user.
[0204] In step S907, if the session to which the message to be pushed belongs does not belong to the preferred session, the message to be pushed is identified as a non-target message, that is, the default push method is used (for example, no message push is performed).
[0205] Secondly, this application provides another method for determining whether the preference settings are met. Using this method, users can set their preferred sessions, meaning that only messages sent to preferred individuals or groups will be pushed to them, while other messages will not notify the user, thus avoiding disturbance.
[0206] Optionally, in the above Figure 5 In addition to one or more corresponding embodiments, another optional embodiment provided in this application may further include:
[0207] If the message content corresponding to the message to be pushed contains a keyword from the preset keyword set, then the message to be pushed is determined to meet the preference setting conditions;
[0208] If the message content corresponding to the message to be pushed does not contain any keywords from the preset keyword set, then it is determined that the message to be pushed does not meet the preference settings.
[0209] In one or more embodiments, another method for determining whether preference settings are met is described. As described in the foregoing embodiments, the message to be pushed can be an IM message. Users can set keywords they are interested in or use keywords recommended by the system. If the message to be pushed matches a keyword, it is determined that the message to be pushed meets the preference settings. In addition, the session to which the message to be pushed belongs can also be designated as a preference session. When a message is received from the preference session, it will be identified as a message that the user is interested in, and the message will be pushed.
[0210] Specifically, for ease of understanding, please refer to Figure 10 , Figure 10 This is a schematic diagram of an interface for setting preferred keywords in an embodiment of this application. As shown in the figure, 1001 indicates a keyword input box, and 1002 indicates a confirmation control. The user can input a keyword (e.g., "work plan") through the keyword input box indicated by 1001. Clicking the control indicated by 1002 completes the setting of that keyword. 1003 indicates the keywords already set by the user; these keywords constitute a preset keyword set.
[0211] It should be noted that users can set different keywords for different scenario types. For example, for the meeting scenario, the preset keyword set includes "group meeting". Another example is for the screen sharing scenario, where the preset keyword set includes "team dinner".
[0212] Based on this, the following will combine Figure 11 This describes the process of identifying push notification messages. Please refer to [link / reference]. Figure 11 , Figure 11 This is another flowchart illustrating the process of identifying the message to be pushed in this application embodiment. As shown in the figure, taking an IM message as an example, the specific steps are as follows:
[0213] Steps S1101 to S1106 in this embodiment are the same as those described above. Figure 9 Steps S901 to S906 in the illustrated embodiment are similar and will not be described in detail here.
[0214] In step S1107, if the session to which the message to be pushed belongs does not belong to the preferred session, it is determined whether the message to be pushed contains keywords. If yes, step S1108 is executed; otherwise, step S1109 is executed.
[0215] In step S1108, if the message to be pushed contains keywords, the message to be pushed is identified as the target message, and a message push is directly initiated to the user.
[0216] In step S1109, if the message to be pushed does not contain keywords, the message to be pushed is identified as a non-target message, that is, the do-not-disturb mode is adopted (for example, no message push is performed).
[0217] It should be noted that when filtering push messages step by step according to preference settings, the execution order of the filtering steps can be flexibly adjusted. This is only an illustration and should not be construed as a limitation of this application.
[0218] Secondly, this application provides another method for determining whether the preference settings are met. Using this method, users can set their preferred keywords; that is, messages containing those keywords will be pushed to the user, while other messages will not, thus avoiding disturbance.
[0219] Optionally, in the above Figure 5 In addition to one or more corresponding embodiments, another optional embodiment provided in this application may further include:
[0220] Get the target message type corresponding to the message to be pushed;
[0221] If the target message type matches any message type in the preset message type set, then the message to be pushed is determined to meet the preference settings.
[0222] If the target message type fails to match any message type in the preset message type set, it is determined that the message to be pushed does not meet the preference settings.
[0223] In one or more embodiments, another method for determining whether preference settings are met is described. As described in the foregoing embodiments, the message to be pushed can be an IM message. Users can set the types of messages they are interested in, such as voice, text, and video calls. If the target message type corresponding to the message to be pushed matches the message type that the user is interested in, then the message to be pushed is determined to meet the preference settings. In addition, the session to which the message to be pushed belongs can also be designated as the preferred session. When a message is received from the preferred session, it will be identified as a message that the user is interested in, and the message will be pushed.
[0224] Specifically, for ease of understanding, please refer to Figure 12 , Figure 12 This is a schematic diagram of an interface for setting message types in an embodiment of this application. As shown in the figure, 1201 indicates a message type input box, and 1202 indicates a drop-down control. When the user clicks the drop-down control indicated by 1202, a list of selectable message types is displayed, and the user can select a message type from the list. 1203 indicates message types that the user has already set; these message types constitute a preset message type set.
[0225] It should be noted that users can set different message types for different scenarios. For example, for meeting scenarios, the preset message type set includes "text" and "voice". For screen sharing scenarios, the preset message type set includes "video call" and "voice call".
[0226] Based on this, the following will combine Figure 13 This describes the process of identifying push notification messages. Please refer to [link / reference]. Figure 13 , Figure 13 This is another flowchart illustrating the process of identifying the message to be pushed in this application embodiment. As shown in the figure, taking an IM message as an example, the specific steps are as follows:
[0227] Steps S1301 to S1306 in this embodiment are the same as those described above. Figure 9 Steps S901 to S906 in the illustrated embodiment are similar and will not be described in detail here.
[0228] In step S1307, if the session to which the message to be pushed belongs does not belong to the preferred session, it is determined whether the message to be pushed contains keywords. If yes, step S1308 is executed; otherwise, step S1309 is executed.
[0229] In step S1308, if the message to be pushed contains keywords, the message to be pushed is identified as the target message, and a message push is directly initiated to the user.
[0230] In step S1309, if the message to be pushed does not contain keywords, it is determined whether the target message type corresponding to the message to be pushed is matched with any message type in the preset message type set. If yes, step S1310 is executed; otherwise, step S1311 is executed.
[0231] In step S1310, if the message to be pushed belongs to the message type preferred by the user, the message to be pushed is identified as the target message and the message is directly pushed to the user.
[0232] In step S1311, if the message to be pushed does not belong to the message type preferred by the user, the message to be pushed is identified as a non-target message, that is, the do-not-disturb mode is adopted (for example, no message push is performed).
[0233] It should be noted that when filtering push messages step by step according to preference settings, the execution order of the filtering steps can be flexibly adjusted. This is only an illustration and should not be construed as a limitation of this application.
[0234] Secondly, this application provides another method for determining whether the preference settings are met. Using this method, users can set their preferred message types; that is, only messages belonging to the user's preferred message type will be pushed to the user, while other messages will not notify the user, thus avoiding disturbance.
[0235] Optionally, in the above Figure 5 In addition to one or more corresponding embodiments, another optional embodiment provided in this application may further include:
[0236] Obtain the target source identifier corresponding to the message to be pushed, whereby the target source identifier is used to indicate the message source of the message to be pushed;
[0237] If the target source identifier matches any source identifier in the preset source identifier set, it is determined that the message to be pushed meets the preference settings.
[0238] If the target source identifier fails to match any of the source identifiers in the preset source identifier set, it is determined that the message to be pushed does not meet the preference settings.
[0239] In one or more embodiments, another method for determining whether preference settings are met is described. As can be seen from the foregoing embodiments, the message to be pushed can be an application message. Users can set their preferred message sources. If the target source identifier corresponding to the message to be pushed matches a source identifier that the user is interested in, then the message to be pushed is determined to meet the preference settings.
[0240] Specifically, for ease of understanding, please refer to Figure 14 , Figure 14 This is a schematic diagram of an interface for setting message sources in an embodiment of this application. As shown in the figure, 1401 indicates the message source input box, and 1402 indicates the drop-down control. When the user clicks the drop-down control indicated by 1402, a list of selectable message sources is displayed, and the user can select a message source from the list. 1403 indicates message sources that the user has already set; the source identifiers corresponding to these message sources form a preset set of source identifiers.
[0241] It should be noted that users can set different message sources for different scenario types. For example, for the meeting scenario, the preset source identifier set includes identifier "1" (i.e., the source identifier corresponding to the AAA application). As another example, for the screen sharing scenario, the preset source identifier set includes identifier "2" (i.e., the source identifier corresponding to the BBB application).
[0242] Secondly, this application provides another method for determining whether the preference settings are met. Using this method, users can set their preferred message sources; that is, messages belonging to the user's preferred message sources will be pushed to them, while other messages will not notify the user, thus avoiding disturbance.
[0243] The following section will use an IM application as an example to introduce the message push system. Please refer to [link / reference needed]. Figure 15 , Figure 15 This is a schematic diagram of the message push system architecture in an embodiment of this application. As shown in the figure, the server and the terminal each include different functional modules, and each functional module is used to perform a corresponding function. Specifically:
[0244] The IM application consists of two parts: a server and a client. When a user uses the IM application, they need to log in through the login management module 1510. At this time, the login information (including username, password, device information, etc.) is synchronized to the server, and the user's online status is updated. The user searches for friends or groups through the group management module 1520 and initiates a conversation. At this time, the IM message sent by the user is first sent to the server, and then the server forwards it to the corresponding friend or group. At the same time, a corresponding conversation window appears on the client, and the conversation management module 1530 is responsible for recording it. When the user receives a new IM message, it is detected by the message management module 1540. The message management module 1540 presents the IM message in the corresponding conversation window and obtains the message notification settings for the current conversation. Based on this, the message preference module 1550 determines whether to allow the IM message to be pushed. If allowed, the message is pushed; if not allowed, the message is not pushed.
[0245] It is worth noting that the message preference module 1550 includes a preference setting unit 15301, a preference condition unit 15302, a message recognition unit 15303, a session protection unit 15304, and a scene recognition unit 15305, which will be introduced separately below.
[0246] The preference setting unit 15301 is responsible for setting user preferences. That is, the received IM message will be determined according to the settings to determine whether it is a message that the user is currently interested in. Only when an IM message that meets the user's preferences arrives will a message push be sent. Otherwise, the user will not be notified to avoid disturbing the user.
[0247] Preference condition unit 15301 is used to set the validity period of user preferences. During this period, only IM messages that match the preference settings will notify the user; other messages will not be notified. After the validity period, push notifications will automatically follow the user's default behavior. Users can also set the scenario types they want to be automatically activated, such as meeting scenarios.
[0248] The message recognition unit 15303 is used to recognize received IM messages, that is, to check whether the IM message belongs to a message that the user is interested in, or whether the IM message corresponds to a session that the user is interested in. If so, a message push is initiated directly; otherwise, the push will be automatically performed according to the user's default behavior.
[0249] The session protection unit 15304 is used to protect IM messages that match preference conditions or the sessions corresponding to those IM messages. When an IM message in a session matches a preference, that session needs to be prioritized to prevent it from being overwritten by non-target message sessions. Therefore, users can see the IM messages and their corresponding sessions first after receiving a notification.
[0250] The scene recognition unit 15305 is used to identify scenarios where frequent interruptions are generally undesirable, such as meeting scenarios, screen sharing scenarios, and media playback scenarios. It proactively identifies scenarios, automatically restricts message notifications when a scenario is entered, and proactively resumes notifications when the scenario is exited.
[0251] The message push device in this application is described in detail below. Please refer to [link / reference]. Figure 16 , Figure 16 This is a schematic diagram of one embodiment of the message push device in this application. The message push device 160 includes:
[0252] The acquisition module 1601 is used to acquire scene recognition results when the message do-not-disturb mode is activated, wherein the scene recognition results represent the scene type currently corresponding to the terminal;
[0253] The push module 1602 is used to push the message to be pushed if the scene recognition result matches any preset scene type in the preset scene type set, provided that the message to be pushed meets the preference setting conditions. The preset scene type set includes at least one of the following: meeting scene type, screen sharing scene type, media playback scene type, and voice acquisition scene type.
[0254] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application,
[0255] The acquisition module 1601 is specifically used to acquire audio acquisition results when the message do-not-disturb mode is activated;
[0256] If the audio capture result indicates the existence of an audio capture identifier belonging to another application, then obtain the current volume mode of the terminal. Here, other applications are applications other than the target application, and the audio capture identifier is used to indicate the audio capture request triggered by the application.
[0257] If the volume mode is call volume mode, then the scene recognition result is determined to be a conference scene type.
[0258] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application,
[0259] The acquisition module 1601 is specifically used to acquire the running status information of the target application when the message do not disturb mode is enabled;
[0260] If the running status information indicates that the target application is running a voice acquisition service, the scene recognition result is determined to be a voice acquisition scene type.
[0261] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application,
[0262] The acquisition module 1601 is specifically used to detect screen recording events when the message do-not-disturb mode is activated;
[0263] If a start notification for a screen recording event is detected, the scene identification result is determined to be a screen sharing scene type.
[0264] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application,
[0265] The acquisition module 1601 is specifically used to acquire audio playback results when the message do-not-disturb mode is activated;
[0266] If the audio playback result indicates that there is an audio playback identifier belonging to another application, then obtain the current volume mode and playback duration of the terminal. Here, other applications are applications other than the target application, and the audio playback identifier is used to indicate the audio playback request triggered by the application.
[0267] If the volume mode is media volume mode and the playback duration is greater than or equal to the duration threshold, then the scene recognition result is determined to be a media playback scene type.
[0268] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application,
[0269] The acquisition module 1601 is specifically used to acquire the running status information of the target application when the message do not disturb mode is enabled;
[0270] If the running status information indicates that the target application is running a media playback service, the scene identification result is determined to be a media playback scene type.
[0271] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application, the message push device 160 further includes a display module 1603;
[0272] Display module 1603 is used to display K scene type options, where each scene type option corresponds to a preset scene type, and K is an integer greater than 1;
[0273] The acquisition module 1601 is further configured to, in response to a selection operation for at least one scene type option among the K scene type options, acquire a preset scene type set, wherein the preset scene type set includes a preset scene type corresponding to each scene type option among the at least one scene type options.
[0274] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application, the message push device 160 further includes a determination module 1604;
[0275] The acquisition module 1601 is also used to acquire the message push time corresponding to the message to be pushed;
[0276] The determination module 1604 is used to determine whether the message to be pushed meets the preference settings if the message push time is within the non-push time range.
[0277] The determination module 1604 is also used to determine that the message to be pushed does not meet the preference settings if the message push time is not within the non-push time range.
[0278] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application, the message push device 160 further includes a construction module 1605;
[0279] The acquisition module 1601 is also used to acquire the target start time in response to a setting operation for the start time;
[0280] The acquisition module 1601 is also used to acquire the target end time in response to a setting operation for the end time;
[0281] Module 1605 is used to construct a non-push time range based on the target start time and target end time.
[0282] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application,
[0283] The acquisition module 1601 is also used to acquire the target session identifier corresponding to the message to be pushed, wherein the target session identifier is used to indicate the session to which the message to be pushed belongs;
[0284] The determination module 1604 is also used to determine that the message to be pushed meets the preference setting conditions if the target session identifier matches any session identifier in the preset session identifier set.
[0285] The determination module 1604 is also used to determine that the message to be pushed does not meet the preference settings if the target session identifier fails to match all session identifiers in the preset session identifier set.
[0286] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application,
[0287] The determination module 1604 is also used to determine that the message to be pushed meets the preference setting conditions if the message content corresponding to the message to be pushed contains a keyword from the preset keyword set.
[0288] The determination module 1604 is also used to determine that the message to be pushed does not meet the preference setting conditions if the message content corresponding to the message to be pushed does not contain any keywords from the preset keyword set.
[0289] Optionally, in the above Figure 16Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application,
[0290] The acquisition module 1601 is also used to acquire the target message type corresponding to the message to be pushed;
[0291] The determination module 1604 is also used to determine that the message to be pushed meets the preference setting conditions if the target message type matches any message type in the preset message type set.
[0292] The determination module 1604 is also used to determine that the message to be pushed does not meet the preference settings if the target message type fails to match all message types in the preset message type set.
[0293] Optionally, in the above Figure 16 Based on the corresponding embodiments, in another embodiment of the message push device 160 provided in this application,
[0294] The acquisition module 1601 is also used to acquire the target source identifier corresponding to the message to be pushed, wherein the target source identifier is used to indicate the message source of the message to be pushed;
[0295] The determination module 1604 is also used to determine that the message to be pushed meets the preference setting conditions if the target source identifier matches any source identifier in the preset source identifier set.
[0296] The determination module 1604 is also used to determine that the message to be pushed does not meet the preference settings if the target source identifier fails to match all source identifiers in the preset source identifier set.
[0297] This application also provides a terminal, such as... Figure 17 As shown, for ease of explanation, only the parts related to the embodiments of this application are shown. For specific technical details not disclosed, please refer to the method section of the embodiments of this application. In the embodiments of this application, a mobile phone is used as an example for illustration:
[0298] Figure 17 This is a block diagram illustrating a portion of the structure of a mobile phone related to the terminal provided in the embodiments of this application. (Reference) Figure 17 The mobile phone includes components such as a radio frequency (RF) circuit 1710, a memory 1720, an input unit 1730, a display unit 1740, a sensor 1750, an audio circuit 1760, a wireless fidelity (WiFi) module 1770, a processor 1780, and a power supply 1790. Those skilled in the art will understand that... Figure 17The mobile phone structure shown does not constitute a limitation on the mobile phone and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0299] The following is combined Figure 17 A detailed introduction to each component of a mobile phone:
[0300] RF circuit 1710 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with processor 1780; additionally, it transmits uplink data to the base station. Typically, RF circuit 1710 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), and a duplexer. Furthermore, RF circuit 1710 can also communicate wirelessly with networks and other devices. The aforementioned wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, and Short Message Service (SMS).
[0301] The memory 1720 can be used to store software programs and modules. The processor 1780 executes various mobile phone functions and data processing by running the software programs and modules stored in the memory 1720. The memory 1720 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 1720 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, or other volatile solid-state storage device.
[0302] The input unit 1730 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the mobile phone. Specifically, the input unit 1730 may include a touch panel 1731 and other input devices 1732. The touch panel 1731, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel 1731), and drive the corresponding connection devices according to a pre-set program. Optionally, the touch panel 1731 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 1780, and can also receive and execute commands sent by the processor 1780. In addition, the touch panel 1731 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 1731, the input unit 1730 may also include other input devices 1732. Specifically, other input devices 1732 may include, but are not limited to, one or more of the following: a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), a mouse, and a joystick.
[0303] The display unit 1740 can be used to display information input by the user or information provided to the user, as well as various menus of the mobile phone. The display unit 1740 may include a display panel 1741, which may optionally be configured as a liquid crystal display (LCD), organic light-emitting diode (OLED), or similar form. Further, a touch panel 1731 may cover the display panel 1741. When the touch panel 1731 detects a touch operation on or near it, it transmits the information to the processor 1780 to determine the type of touch event. Subsequently, the processor 1780 provides corresponding visual output on the display panel 1741 based on the type of touch event. Although in Figure 17 In this embodiment, the touch panel 1731 and the display panel 1741 are two separate components to realize the input and output functions of the mobile phone. However, in some embodiments, the touch panel 1731 and the display panel 1741 can be integrated to realize the input and output functions of the mobile phone.
[0304] The mobile phone may also include at least one sensor 1750, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 1741 according to the ambient light level, and the proximity sensor can turn off the display panel 1741 and / or the backlight when the phone is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used for applications that recognize the phone's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometer, taps), etc. Other sensors that may be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.
[0305] Audio circuit 1760, speaker 1761, and microphone 1762 provide an audio interface between the user and the mobile phone. Audio circuit 1760 converts received audio data into electrical signals and transmits them to speaker 1761, where speaker 1761 converts them into sound signals for output. On the other hand, microphone 1762 converts collected sound signals into electrical signals, which are received by audio circuit 1760, converted into audio data, and then processed by processor 1780 before being transmitted via RF circuit 1710 to, for example, another mobile phone, or the audio data can be output to memory 1720 for further processing.
[0306] WiFi is a short-range wireless transmission technology. Mobile phones using the WiFi module 1770 can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access. Although Figure 17 WiFi module 1770 is shown, but it is understood that it is not an essential component of a mobile phone and can be omitted as needed without changing the essence of the invention.
[0307] The processor 1780 is the control center of the mobile phone, connecting various parts of the phone through various interfaces and lines. It executes various functions and processes data by running or executing software programs and / or modules stored in the memory 1720 and calling data stored in the memory 1720. Optionally, the processor 1780 may include one or more processing units; optionally, the processor 1780 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the aforementioned modem processor may also not be integrated into the processor 1780.
[0308] The phone also includes a power supply 1790 (such as a battery) that supplies power to various components. Optionally, the power supply can be logically connected to the processor 1780 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.
[0309] Although not shown, mobile phones may also include a camera, Bluetooth module, etc., which will not be described in detail here.
[0310] The steps performed by the terminal in the above embodiments can be based on this Figure 17 The terminal structure shown.
[0311] This application also provides a computer device, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the methods described in the foregoing embodiments.
[0312] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the methods described in the foregoing embodiments.
[0313] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods described in the foregoing embodiments.
[0314] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0315] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.
[0316] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of 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 system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.
[0317] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0318] 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.
[0319] 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 computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a server or terminal device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0320] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.
Claims
1. A method for message push, characterized in that, include: When the message do-not-disturb mode is activated, the scene recognition result is obtained, wherein the scene recognition result represents the scene type currently corresponding to the terminal; If the scene recognition result matches any preset scene type in the preset scene type set, then the message to be pushed will be pushed if the message to be pushed meets the preference setting conditions. The preset scene type set includes at least one of the following: meeting scene type, screen sharing scene type, media playback scene type, and voice acquisition scene type.
2. The method according to claim 1, characterized in that, When the message do-not-disturb mode is activated, obtaining the scene recognition result includes: Obtain audio capture results while the message do-not-disturb mode is enabled; If the audio acquisition result indicates the existence of an audio acquisition identifier belonging to another application, then the current volume mode of the terminal is obtained, wherein the other application is an application other than the target application, and the audio acquisition identifier is used to indicate an audio acquisition request triggered by the application; If the volume mode is a call volume mode, then the scene recognition result is determined to be the conference scene type.
3. The method according to claim 1, characterized in that, When the message do-not-disturb mode is activated, obtaining the scene recognition result includes: When the Do Not Disturb mode is enabled, obtain the running status information of the target application; If the running status information indicates that the target application is running a voice acquisition service, the scene recognition result is determined to be the voice acquisition scene type.
4. The method according to claim 1, characterized in that, When the message do-not-disturb mode is activated, the scene recognition result is obtained, including: When Do Not Disturb mode is enabled, screen recording events are detected; If a start notification for the screen recording event is detected, the scene identification result is determined to be the screen sharing scene type.
5. The method according to claim 1, characterized in that, When the message do-not-disturb mode is activated, the scene recognition result is obtained, including: Obtain audio playback results while the Do Not Disturb mode is enabled; If the audio playback result indicates the existence of an audio playback identifier belonging to another application, then the current volume mode and playback duration of the terminal are obtained, wherein the other application is an application other than the target application, and the audio playback identifier is used to indicate an audio playback request triggered by an application. If the volume mode is a media volume mode, and the playback duration is greater than or equal to a duration threshold, then the scene identification result is determined to be a media playback scene type.
6. The method according to claim 1, characterized in that, When the message do-not-disturb mode is activated, the scene recognition result is obtained, including: When the Do Not Disturb mode is enabled, obtain the running status information of the target application; If the running status information indicates that the target application is running a media playback service, the scene identification result is determined to be the media playback scene type.
7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Display K scene type options, where each scene type option corresponds to a preset scene type, and K is an integer greater than 1; In response to a selection operation for at least one of the K scene type options, the preset scene type set is obtained, wherein the preset scene type set includes the preset scene type corresponding to each of the at least one scene type options.
8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Obtain the message push time corresponding to the message to be pushed; If the message push time is within the non-push time range, then the message to be pushed is determined to meet the preference setting conditions; If the message push time is not within the non-push time range, then it is determined that the message to be pushed does not meet the preference setting conditions.
9. The method according to claim 8, characterized in that, The method further includes: In response to a setting operation for the start time, obtain the target start time; In response to a setting operation for the end time, obtain the target end time; The non-push time range is constructed based on the target start time and the target end time.
10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: Obtain the target session identifier corresponding to the message to be pushed, wherein the target session identifier is used to indicate the session to which the message to be pushed belongs; If the target session identifier matches any session identifier in the preset session identifier set, then the message to be pushed is determined to meet the preference setting conditions. If the target session identifier fails to match any of the session identifiers in the preset session identifier set, then the message to be pushed does not meet the preference setting conditions.
11. The method according to any one of claims 1 to 10, characterized in that, The method further includes: If the message content corresponding to the message to be pushed contains a keyword from the preset keyword set, then the message to be pushed is determined to meet the preference setting conditions; If the message content corresponding to the message to be pushed does not contain any keywords from the preset keyword set, then it is determined that the message to be pushed does not meet the preference setting conditions.
12. The method according to any one of claims 1 to 11, characterized in that, The method further includes: Obtain the target message type corresponding to the message to be pushed; If the target message type matches any message type in the preset message type set, then the message to be pushed is determined to meet the preference setting conditions. If the target message type fails to match any of the message types in the preset message type set, then the message to be pushed does not meet the preference setting conditions.
13. The method according to any one of claims 1 to 12, characterized in that, The method further includes: Obtain the target source identifier corresponding to the message to be pushed, wherein the target source identifier is used to indicate the message source of the message to be pushed; If the target source identifier matches any source identifier in the preset source identifier set, then the message to be pushed is determined to meet the preference setting conditions. If the target source identifier fails to match any of the source identifiers in the preset source identifier set, then the message to be pushed does not meet the preference setting conditions.
14. A message push device, characterized in that, include: The acquisition module is used to acquire scene recognition results when the message do-not-disturb mode is activated, wherein the scene recognition results represent the scene type currently corresponding to the terminal; The push module is used to push the message to be pushed if the scene recognition result matches any preset scene type in the preset scene type set, provided that the message to be pushed meets the preference setting conditions. The preset scene type set includes at least one of the following: meeting scene type, screen sharing scene type, media playback scene type, and voice acquisition scene type.
15. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 13.
16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 13.
17. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 13.
