Multi-system message notification management method, management system and electronic equipment

Abstract

The invention provides a multi-system message notification management method, a management system and electronic equipment. The multi-system message notification management method comprises the following steps: receiving notification requests from a plurality of independent operating systems; based on the notification request, determining the content of the to-be-displayed notification and the corresponding priority; according to the determined priorities, the notifications to be displayed are included in a unified management queue; and controlling the display output of the to-be-displayed notification on the display interface according to the sequence of the management queue. The technical problems that in the prior art, message notifications between different systems are parallel and lack of a collaborative mechanism, so that the notifications from the different systems directly conflict and compete on the display level, the experience feeling of a user is reduced when the user faces the chaos, and the user may miss key information are solved.

Description

Technical Field

[0001] This application relates to the technical field, and more specifically, to a multi-system message notification management method, management system, and electronic device. Background Technology

[0002] With the increasing computing power of smart terminal devices and the growing complexity of application scenarios, a single operating system can no longer meet users' needs for all functions. Therefore, a technical solution has emerged that allows multiple independent operating systems to run simultaneously on the same hardware device. For example, in smart cockpits or some tablets, the Linux operating system is often used to provide stable core services and high-performance graphics rendering, while the Android operating system is used to ensure compatibility with a rich mobile application ecosystem.

[0003] However, in this multi-system coexistence environment, each operating system has its own independent message notification mechanism. When the system or application has an event that needs to be notified to the user, the Linux system usually pops up a notification through its desktop environment's notification service, while the Android system displays the notification through its own NotificationManager.

[0004] However, the relevant technologies have at least one of the following problems: In the existing technologies, message notifications between different systems are parallel and lack a coordination mechanism, which leads to direct conflicts and competition between notifications from different systems at the display level. When faced with this chaos, users experience a decline in quality and may miss key information. Summary of the Invention

[0005] The technical problem addressed by this application is that in the prior art, message notifications between different systems are parallel and lack a coordination mechanism, which leads to direct conflicts and competition between notifications from different systems at the display level. When faced with this chaos, users experience a decline in quality and may miss key information.

[0006] To address the aforementioned issues, this application provides a multi-system message notification management method, comprising: receiving notification requests from multiple independent operating systems; determining the content and corresponding priority of the notification to be displayed based on the notification requests; incorporating the notifications to be displayed into a unified management queue according to the determined priority; and controlling the display output of the notifications to be displayed on the display interface according to the order of the management queue.

[0007] Compared with existing technologies, the technical effects achieved by adopting this technical solution are as follows: This application effectively avoids display conflicts of notifications from multiple systems, ensures that key information reaches users first, eliminates the fragmentation of notification mechanisms from different systems through a unified queue management mechanism, reduces the frequency of user operation interruptions, and the dynamic priority adjustment function can respond to sudden high-priority notifications in a timely manner, preventing important information from being submerged in the low-value notification stream.

[0008] In one instance of this application, determining the content of the notification to be displayed and its corresponding priority based on the notification request includes: parsing a predefined template identifier carried in the notification request; retrieving the corresponding notification content template from a pre-stored template library based on the template identifier; and querying a pre-established mapping relationship between template identifiers and priorities based on the template identifier to determine the corresponding priority.

[0009] Compared with the prior art, the technical effects achieved by adopting this technical solution are as follows: This application solves the display misalignment problem caused by differences in content format in a multi-system environment, eliminates the judgment conflict caused by different systems using independent priority rules, ensures that high-priority notifications can accurately seize display resources, and avoids key information being covered by low-priority notifications.

[0010] In one instance of this application, when the notification request includes variable parameters, the variable parameters are filled into the corresponding positions of the obtained notification content template to generate the final notification display content.

[0011] Compared with existing technologies, the technical effects achieved by this solution are as follows: This application effectively solves the problem of repetitive development of message templates in multi-system environments, enabling the same template to adapt to dynamic notification scenarios with different parameter combinations. In the intelligent cockpit system, hardware alarm notifications generated by the Linux system and application update notifications pushed by the Android system can both generate standardized display content through a unified battery status template combined with real-time percentage parameters, ensuring that notifications from different system sources maintain consistent format in interface presentation, while also achieving dynamic updates of key parameters.

[0012] In one instance of this application, when the notification request contains a complete message text, the message text is directly determined as the content of the notification to be displayed.

[0013] Compared with the prior art, the technical effect achieved by adopting this technical solution is: This application effectively reduces the processing time of notification requests that already contain complete content, enabling high-priority messages to skip redundant processing steps and enter the display queue first.

[0014] In one example of this application, the message text is parsed, and its priority is determined according to the identified keywords or message type and a preset priority rule.

[0015] Compared with existing technologies, the technical effects achieved by this solution are as follows: This application solves the problem that complete message text cannot be dynamically prioritized, enabling messages containing urgent content to be accurately identified and prioritized for display, avoiding the omission of key information due to misjudgment of priority. Simultaneously, through a unified rule mapping mechanism, it ensures that similar messages generated by different operating systems receive consistent priority processing standards.

[0016] In one instance of this application, notifications to be displayed are included in a unified management queue according to a determined priority, including: inserting notifications to be displayed into the management queue in order of their priority, wherein notifications with higher priority are placed at the beginning of the queue.

[0017] Compared with existing technologies, the technical effects achieved by this solution are as follows: This application solves the problem of critical information being obscured due to disordered notification display order in multi-system environments, ensuring that high-priority notifications are displayed first regardless of the system they originate from. Simultaneously, the dynamic insertion mechanism of the queue allows newly arriving high-priority notifications to immediately preempt display resources, avoiding processing delays caused by static queue sorting. This solution maintains the original notification mechanisms of each operating system while achieving cross-system collaboration through external queue management, without requiring modifications to the underlying system architecture.

[0018] In one instance of this application, the head notification of the management queue is monitored in real time; when the priority of the head notification is higher than the priority of the currently displayed notification, the display of the current notification is interrupted and the head notification is displayed immediately.

[0019] Compared with existing technologies, the technical effects achieved by adopting this technical solution are as follows: In scenarios where multiple systems send notifications in parallel, this application can dynamically adjust the display priority order, avoid low-priority notifications occupying the display interface for a long time, and ensure that urgent or critical information is presented immediately after it is generated, thereby reducing the risk of users missing important information.

[0020] On the other hand, this application also provides a management system, including a message notification management method as in any of the above examples, comprising: a request receiving module for receiving notification requests from multiple independent operating systems; a processing module for determining the content of the notification to be displayed and its corresponding priority based on the notification request; a queue management module for including the notification to be displayed in a unified management queue according to the determined priority; and a display control module for controlling the display output of the notification to be displayed on the display interface according to the order of the management queue.

[0021] Compared with existing technologies, the technical effects achieved by this solution are as follows: This solution solves the problem of user interface chaos caused by competition in the notification display layer under multiple operating system environments.

[0022] In one instance of this application, the standalone operating system includes the Linux operating system and the Android operating system.

[0023] Compared with the existing technology, the technical effects achieved by adopting this technical solution are as follows: This application solves the problem of notification display conflict caused by the independent message notification mechanism of Linux and Android systems in a multi-system coexistence environment, avoids the overlapping and covering of notification pop-ups in the user interface, ensures that high-priority notifications can reach users in a timely manner, and reduces the interference of low-priority notifications on user operations.

[0024] On the other hand, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement a message notification management method including any of the above examples.

[0025] Compared with existing technologies, the technical effects achieved by adopting this technical solution are as follows: it can achieve the technical effects corresponding to any of the above examples, which will not be elaborated here.

[0026] By adopting the technical solution of this application, the following technical effects can be achieved: (1) This application solves the problem of display conflict of notifications from multiple systems by unifying the management queue, thus eliminating interface clutter; (2) Through a dynamic priority management mechanism, ensure that key information is displayed first and prevent important notices from being buried; (3) The use of template and parameter filling technology significantly reduces the communication overhead between systems and improves processing efficiency and flexibility. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 A schematic diagram illustrating the specific process of a multi-system message notification management method provided in this application; Figure 2 This is a schematic diagram illustrating the specific operational process for managing queues. Detailed Implementation

[0028] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following drawings indicate similar items; therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0029] In existing technologies, smart terminal devices often employ a multi-operating system architecture to meet different functional requirements. For example, a smart cockpit might run both Linux and Android systems simultaneously. Each operating system maintains its own message notification mechanism; Linux displays notifications via desktop services, while Android displays notifications through NotificationManager. Due to the lack of a cross-system collaboration mechanism, notifications from different sources compete and conflict at the display level, leading to a cluttered user interface and the risk of critical information being overwritten by lower-priority notifications.

[0030] To address the aforementioned issues, the inventors observed that notification conflicts in multi-system environments stem from fragmented resource scheduling mechanisms. Traditional solutions only optimize notification ordering within a single system, neglecting the unique characteristics of cross-system scenarios. By analyzing the spatiotemporal distribution characteristics of notifications generated when multiple systems coexist, they discovered that establishing a global priority evaluation model and a unified queue management mechanism is crucial to solving the problem. Based on this, they proposed constructing a cross-system notification acquisition interface and an intelligent hierarchical processing module to achieve normalized processing of notifications from different sources.

[0031] Therefore, this application provides a multi-system message notification management method, including: receiving notification requests from multiple independent operating systems; determining the content of the notification to be displayed and its corresponding priority based on the notification request; including the notification to be displayed in a unified management queue according to the determined priority; and controlling the display output of the notification to be displayed on the display interface according to the order of the management queue.

[0032] Specifically, the module first receives notification requests from multiple independent operating systems: it runs on the human-computer interaction layer (HMI) of one of these operating systems, such as Linux, and establishes communication connections with both Linux and Android systems. Through these connections, the module can receive notification display requests from any of these systems.

[0033] Secondly, the message notification module needs to parse the request and determine what content to display and its priority.

[0034] Then, all notifications to be displayed, regardless of which system they come from, are placed into the same queue according to their priority for centralized scheduling.

[0035] Finally, the message notification module is responsible for retrieving notifications from the queue in sequence and controlling their display on the screen, thereby ensuring that at any given time, the user usually only sees one notification that is uniformly controlled and output by the central module, avoiding the confusion caused by multiple notifications popping up at the same time.

[0036] In one instance of this application, determining the content of the notification to be displayed and its corresponding priority based on the notification request includes: parsing a predefined template identifier carried in the notification request; retrieving the corresponding notification content template from a pre-stored template library based on the template identifier; and querying a pre-established mapping relationship between template identifiers and priorities based on the template identifier to determine the corresponding priority.

[0037] Specifically, the system predefines a series of common notification templates, each with a unique ID. When the system needs to display such a predefined notification, it simply needs to include this ID in the request.

[0038] Furthermore, the message notification module maintains a template database. By querying the received ID, a pre-set notification content template can be obtained.

[0039] Furthermore, the module also maintains a "template ID-priority" mapping table. By querying this table, the priority of the notification can be directly determined. This approach makes the determination of content and priority highly efficient.

[0040] In one instance of this application, when the notification request includes variable parameters, the variable parameters are filled into the corresponding positions of the obtained notification content template to generate the final notification display content.

[0041] Specifically, the notification content template is designed to include a fixed part and a variable parameter part. When the notification request contains variable parameters in addition to the template ID, the message notification module will perform a parameter population operation, filling the parameter values ​​into the reserved positions in the template, thereby generating the final, personalized notification display content.

[0042] In one instance of this application, when the notification request contains a complete message text, the message text is directly determined as the content of the notification to be displayed.

[0043] Specifically, to ensure compatibility with new notification types that are not predefined, the system allows systems initiating notification requests to submit the complete message text directly, without passing the template ID. Upon receiving such a request, the notification module will directly determine this text as the content to be displayed.

[0044] In one example of this application, the message text is parsed, and its priority is determined according to the identified keywords or message type and a preset priority rule.

[0045] Specifically, message parsing refers to the process of semantic analysis of the complete text content carried in a notification request. This can be achieved using natural language processing algorithms, which extract entity words from the text through word segmentation technology, providing a data foundation for subsequent priority determination.

[0046] Furthermore, keyword or message type identification refers to matching predefined classification labels from the parsed text. This can be achieved using rule engines or machine learning models. For example, a matching rule library containing keywords such as "fault," "warning," and "update" can be established, or a text classification model can be trained to identify the business type to which the message belongs.

[0047] Furthermore, the preset priority rules refer to the pre-established mapping relationship between category labels and priority levels. This can be implemented using database tables or configuration files. For example, "emergency faults" can be mapped to the highest priority, and "regular reminders" can be mapped to the lowest priority, forming a dynamically adjustable judgment standard.

[0048] Specifically, when a notification request containing the complete message text is received, the message text is first segmented using a semantic analysis module to extract core words and contextual structure. Next, the extracted words are matched against a predefined keyword library. If high-risk words such as "system crash" or "data loss" are detected, an alarm type identification is triggered; if neutral words such as "version upgrade" or "service maintenance" are detected, it is classified as a regular notification type. Finally, according to a pre-configured rule table, the identified message type is automatically mapped to a corresponding priority value. For example, alarm messages are assigned priority 9, and regular messages are assigned priority 3, thus achieving dynamic sorting based on the content itself.

[0049] In one instance of this application, notifications to be displayed are included in a unified management queue according to a determined priority, including: inserting notifications to be displayed into the management queue in order of their priority, wherein notifications with higher priority are placed at the beginning of the queue.

[0050] Specifically, notifications to be displayed are inserted into a queue according to their priority, ensuring that higher-priority notifications are placed at the front of the queue. This can typically be achieved by performing a sorting comparison during insertion, thus guaranteeing that the highest-priority notification to be displayed is always at the head of the queue.

[0051] Specifically, after notification requests from different operating systems are parsed, their priorities are determined through preset mapping relationships or keyword recognition rules. Each notification carries a priority value, and the queue management module compares the new notification with existing elements in the queue level by level based on this value until a position with a lower priority than the current notification is found for insertion. The head of the queue always holds the highest priority notification, and the display control module processes notification display requests sequentially according to the queue order. When a high-priority notification is inserted at the head of the queue, the display control module immediately interrupts the display process of the current low-priority notification and prioritizes rendering the high-priority content.

[0052] In one instance of this application, the head notification of the management queue is monitored in real time; when the priority of the head notification is higher than the priority of the currently displayed notification, the display of the current notification is interrupted and the head notification is displayed immediately.

[0053] Among them, the real-time monitoring and management of queue head notification refers to the continuous detection of the highest priority pending notification in the queue through a polling mechanism or an event-driven mechanism. Specifically, it can be implemented by using a timer to trigger the query operation or by triggering the monitoring logic based on queue change events. This feature ensures that the system can perceive queue status changes in real time.

[0054] Furthermore, interrupting the display of the current notification means forcibly terminating the ongoing notification display process. This can be achieved by calling the display control interface to send a termination command or by directly clearing the current display buffer. This feature is used to release display resources so that higher priority notifications can be processed first.

[0055] Furthermore, immediately displaying the top-priority notification means directly pushing the highest-priority notification content in the queue to the display interface. This can be achieved by preloading display data or establishing a display channel preemption mechanism. This feature ensures that high-priority notifications can be presented to the user without delay.

[0056] Specifically, when multiple notifications awaiting display exist in the management queue, the queue management module continuously tracks the priority status of the element at the head of the queue. Before each display operation, the display control module compares the priority of the notification at the head of the queue with the priority of the currently displayed notification. If the notification at the head of the queue has a higher priority, the display control module generates an interrupt signal to terminate the current display process and simultaneously calls the display driver interface to load the content data of the notification at the head of the queue, completing the display switch. This process, through real-time priority determination and dynamic allocation of display resources, ensures that critical information can overcome queue order limitations.

[0057] On the other hand, this application also provides a management system, including a message notification management method as in any of the above examples, comprising: a request receiving module for receiving notification requests from multiple independent operating systems; a processing module for determining the content of the notification to be displayed and its corresponding priority based on the notification request; a queue management module for including the notification to be displayed in a unified management queue according to the determined priority; and a display control module for controlling the display output of the notification to be displayed on the display interface according to the order of the management queue.

[0058] The request receiving module is a communication interface used to receive notification requests from multiple independent operating systems. Its function is to eliminate the differences in communication protocols between different systems and achieve unified access to heterogeneous notifications.

[0059] Furthermore, the processing module refers to the logical unit that generates content and determines the priority of notification requests. Its function is to convert notification content of different formats into a standardized data structure and provide a basis for priority ranking.

[0060] Furthermore, the queue management module refers to the storage structure that maintains the global notification queue. Its function is to break down the physical isolation between the independent maintenance of queues by each system and establish a unified logical sorting mechanism.

[0061] Furthermore, the display control module refers to the execution unit of the scheduling notification display process. Its function is to enforce the priority preemption rule and ensure a strict correspondence between the queue order and the display behavior.

[0062] Specifically, when multiple independent operating systems generate notification requests, the request receiving module receives notification data from different systems through a standardized interface. The processing module selects the parsing path based on the notification content type: for notifications carrying template identifiers, it calls a pre-stored template to generate content and queries a mapping table to determine priority; for complete text notifications, it extracts keywords and matches them against preset rules to determine priority. The queue management module inserts processed notifications into a global queue according to priority, with high-priority notifications automatically moved to the head of the queue. The display control module continuously monitors the queue status; when it detects that the priority of the notification at the head of the queue is higher than the currently displayed content, it immediately terminates the display process of the low-priority notification and starts the rendering output of the high-priority notification, ensuring that key information is presented first.

[0063] In one instance of this application, the standalone operating system includes the Linux operating system and the Android operating system.

[0064] Specifically, when the Linux operating system generates a notification request through the desktop environment notification service, this request is captured and parsed by the management system; similarly, when the Android operating system generates a notification request through NotificationManager, this request is also captured and parsed by the management system. After the notification requests from both systems are converted to a unified format, their display order is determined according to preset priority rules. For example, core service alarm notifications generated by the Linux system may be assigned high priority, while application push notifications from the Android system may be assigned low priority. By inserting the two types of notifications into the management queue according to priority, when a high-priority notification arrives at the front of the queue, the currently displayed low-priority notification will be interrupted, ensuring that critical information is displayed first. Thus, the notification mechanisms of the two heterogeneous systems are integrated into the same scheduling framework, avoiding display resource contention issues caused by system differences.

[0065] In some specific implementations, the Linux operating system can run on the main control chip of the smart cockpit device, responsible for vehicle status monitoring; the Android operating system can run on the coprocessor of the same device, responsible for in-vehicle entertainment applications. When the Linux system generates a low battery warning notification, this notification is given the highest priority, and even if a music playback notification from the Android system is currently being displayed, the display will immediately switch to the battery warning.

[0066] On the other hand, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement a message notification management method including any of the above examples.

[0067] Among them, memory refers to the storage medium used to store computer programs, and is used to persistently save message notification management rules and processing logic.

[0068] Furthermore, a processor is a computational unit that executes computer program instructions, used to parse notification requests from multiple operating systems and perform priority determination and queue management operations.

[0069] Furthermore, a computer program refers to a collection of code containing logic for message notification management methods, used to force all notification requests to go through a unified processing flow.

[0070] See Figure 1 In summary, the specific process of a multi-system message notification management method is as follows: S1. Accept the notification request; S2. Determine the type of notification request; S3. If it is determined to be a predefined template request, then parse the template ID and proceed to S5; S4. If it is determined to be a request for complete copy, then read the complete copy and proceed to S6; S5. Retrieve the content template and priority based on the ID, and proceed to S7; S6. Analyze the complete copywriting dynamically to determine the priority, and then proceed to S7; S7. Generate a notification object to be displayed; S8. Insert into the management queue according to priority.

[0071] See Figure 2 The specific operations for managing queues are as follows: S9. Determine if the current queue is empty or if the current display priority is higher. S10. If the determination is negative, wait and re-enter S9; S11. If the determination is yes, then retrieve the highest priority notification from the head of the queue and display it on the screen.

[0072] In one specific embodiment, the specific working process is as follows: When an event occurs in a Linux or Android system that requires a notification, it sends a request to the message notification module on the Linux HMI. The following explains two different scenarios.

[0073] Scenario 1: Display a predefined notification, as follows: For example, if the Android system detects an account conflict, instead of constructing a complete notification message, it sends a predefined template ID, such as MSG_ACCOUNT_CONFLICT, along with variable parameters such as the account name "Driver01" to the notification module.

[0074] The message notification module's request receiving module receives the request.

[0075] The processing module then parses out the template ID MSG_ACCOUNT_CONFLICT.

[0076] Based on this ID, retrieve the content template from the template library. The template is "Account [account] is logged in elsewhere, you have been forcibly logged out".

[0077] Based on the same ID, query its priority from the priority mapping table, assuming it is "high".

[0078] Fill the variable parameter "Driver01" into the [account] position of the template to generate the final content: "Account Driver01 is logged in elsewhere, you have been forcibly logged out".

[0079] Subsequently, the queue management module inserts this notification, which contains the content "Account Driver01..." and has a priority of "high", into the front position of the priority queue.

[0080] When the display control module detects a high-priority notification in the queue, it displays it on the cockpit screen.

[0081] Scenario 2: Displaying an undefined notification, as follows: Suppose a Linux application needs to display a new, unregistered notification with the message "Custom plugin failed to load, please check configuration". It can directly send this complete message to the message notification module.

[0082] After the processing module receives it: This text was directly adopted as the content of the notification.

[0083] Analyzing the copy revealed that the keyword "failure" has a high priority according to the preset rules, so its priority was set to "high".

[0084] Assign it a temporary ID for management purposes.

[0085] The queue management module and display control module then process the notification according to the established procedure.

[0086] While this application discloses the above information, it is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application shall be determined by the scope defined in the claims.

Claims

1. A multi-system message notification management method, characterized by, The method comprises: receiving notification requests from multiple independent operating systems; determining the content and corresponding priority of the to-be-displayed notification based on the notification request; according to the determined priority, incorporating the to-be-displayed notification into a unified management queue; controlling the display output of the to-be-displayed notification on the display interface according to the order of the management queue.

2. The message notification management method according to claim 1, characterized by, The method further comprises: parsing a predefined template identifier carried in the notification request; obtaining a corresponding notification content template from a pre-stored template library according to the template identifier; querying a pre-established mapping relationship between the template identifier and the priority to determine the corresponding priority.

3. The method of claim 2, wherein: when the notification request includes variable parameters, the variable parameters are filled into the corresponding positions of the obtained notification content template to generate the final notification display content.

4. The method of claim 1, wherein: when the notification request is a complete message script, the message script is directly determined as the content of the to-be-displayed notification.

5. The method of claim 4, wherein: the message script is parsed, and according to the identified keywords or message types, the priority thereof is determined according to a preset priority rule.

6. The message notification management method of claim 1, wherein The method further comprises: inserting the to-be-displayed notification into the management queue according to its priority, wherein the notification with high priority is located at the front of the queue.

7. The method of claim 6, wherein: the head notification of the management queue is monitored in real time; when the priority of the head notification is higher than that of the currently displayed notification, the display of the current notification is interrupted, and the head notification is displayed immediately.

8. A management system adapted to the message notification management method according to any one of claims 1 to 7, characterized by The system comprises: a request receiving module configured to receive notification requests from multiple independent operating systems; a processing module configured to determine the content and corresponding priority of the to-be-displayed notification based on the notification request; a queue management module configured to incorporate the to-be-displayed notification into a unified management queue according to the determined priority; a display control module configured to control the display output of the to-be-displayed notification on the display interface according to the order of the management queue.

9. The system of claim 8, wherein: the independent operating systems include Linux operating systems and Android operating systems.

10. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the message notification management method of any one of claims 1 to 7.

Images