Monitoring method and system of mobile terminal operating system

Abstract

The invention provides a method and a system for monitoring an operating system of a mobile terminal, and the method comprises the steps: a system event manager records and broadcasts an occurring system event, and triggers the initialization of an application performance monitoring service assembly; a system event receiver monitors a system event, and an omission event detector checks the system event in a backtracking time window, determines an event to be processed and sends event data corresponding to the event to a local storage manager; the local storage manager stores the event data into a local database and arranges the event data into data to be reported; and the batch reporting manager periodically acquires the to-be-reported data and reports the to-be-reported data to the remote server. By means of the method, the integrity and stability of system event monitoring are improved, and then the stability and efficiency of processing and reporting the system data are improved.

Description

Technical Field

[0001] This application relates to the field of mobile terminal operating system monitoring technology, and in particular to a monitoring method and system for a mobile terminal operating system. Background Technology

[0002] Currently, mainstream Android application performance monitoring technologies all adopt an application-level monitoring mode. This technology requires the integration of specific software development tools into each target application. When the application runs, it actively calls the interface provided by the software development tool to collect performance data, and then reports the data to the server through the application's own network permissions.

[0003] The above methods have high deployment costs and low application monitoring coverage. They require modification of application code during deployment and may introduce compatibility issues. These methods rely solely on real-time event listening mechanisms, which can easily miss critical system events when the monitoring service restarts or becomes temporarily unavailable, reducing the completeness of system event monitoring. They also reduce the stability of data processing and reporting when the network is unstable or the server fails. Furthermore, these methods still perform heavyweight monitoring operations when the system is busy, reducing the utilization of system resources. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a monitoring method and system for a mobile terminal operating system. By recording and broadcasting system events that occur in the operating system through the system event manager, the system event receiver listens for system events, while the missed event detector checks system events within the backtracking time window. Then, the local storage manager stores the identified events to be processed locally, and the batch reporting manager periodically retrieves the data to be reported from the local storage and reports it to the remote server. This improves the completeness and stability of system event monitoring, thereby improving the stability and efficiency of system data processing and reporting.

[0005] This application provides a monitoring method for a mobile terminal operating system, which is applied to a monitoring system for the mobile terminal operating system. The monitoring system includes a system event receiver, a system event manager, a missed event detector, a local storage manager, and a batch reporting manager. The monitoring method includes: In response to at least one system event occurring in the operating system configured on the target mobile terminal, the system event manager records and broadcasts the system event, and triggers the application performance monitoring service component set by the operating system to initialize each device in the monitoring system; In response to the completion of the initialization of the monitoring system, the system event receiver listens for the system events, and the missed event detector checks the system events within the backtracking time window to determine the pending events in the system events, and sends the event data corresponding to the pending events to the local storage manager. The local storage manager receives the event data and stores it in the local database set by the operating system. In the local database, the event data is organized into data to be reported. The batch reporting manager periodically retrieves the data to be reported from the local database and reports the data to be reported to the remote server corresponding to the operating system via a preset network.

[0006] Furthermore, in response to the completion of the monitoring system initialization, the system event receiver listens for system events, and the missed event detector checks the system events within the backtracking time window to identify pending events among the system events, and sends the event data corresponding to the pending events to the local storage manager, including: In response to the completion of the initialization of the monitoring system, the system event receiver listens for the system events broadcast by the system event manager, determines the pending events in the system events, and sends the event data corresponding to the pending events to the local storage manager; In response to the completion of the initialization of the monitoring system, the missed event detector checks the system events broadcast by the system event manager within the backtracking time window, and when a missed event is detected, the missed event is sent to the system event receiver; In response to receiving a missed event sent by the missed event detector, the system event receiver determines whether the missed event is an event to be processed, and if the missed event is an event to be processed, sends the event data corresponding to the missed event to the local storage manager.

[0007] Furthermore, the step of the system event receiver listening to the system events broadcast by the system event manager and determining the pending events in the system events includes: The system event receiver receives the system events broadcast by the system event manager and obtains the system information corresponding to each system event; For each system event, based on the system information, a memory deduplication check and a database deduplication check are performed on the system event respectively; When a system event passes the memory deduplication check and the database deduplication check, it is determined whether the system event has been processed. Discard the system event once it has been processed; When a system event is not processed, it is designated as a pending event.

[0008] Furthermore, in response to the monitoring system completing initialization, the missed event detector checks the system events broadcast by the system event manager within the backtracking time window, and when a missed event is detected, sends the missed event to the system event receiver, including: In response to the completion of the initialization of the monitoring system, the missed event detector determines the time step corresponding to the backtracking time window based on the current time; The system events broadcast by the system event manager are traversed according to a preset target event type in order to check for any missing events that represent the target event type in the system events; When the omitted event is detected in the system events, a simulated network is constructed and the omitted event is sent to the system event receiver through the simulated network.

[0009] Furthermore, the step of receiving the event data by the local storage manager, storing the event data in the local database set by the operating system, and organizing the event data into data to be reported in the local database includes: The local storage manager receives the event data and verifies whether the event data meets the preset valid integrity conditions. The event data that meets the valid integrity conditions is stored in the local database set by the operating system; In the local database, data uniqueness constraints corresponding to the event data are generated, and the event data is organized into data to be reported.

[0010] Furthermore, the step of receiving the event data by the local storage manager, storing the event data in the local database set by the operating system, and organizing the event data into data to be reported in the local database also includes: In response to the batch reporting manager reporting the data to be reported to the remote server, the local storage manager deletes the reported data to be reported.

[0011] Furthermore, the step of periodically retrieving the data to be reported from the local database by the batch reporting manager and reporting the data to be reported to the remote server corresponding to the operating system via a preset network includes: The batch reporting manager periodically retrieves the data to be reported from the local database; The data to be reported is sequentially processed through structured processing and encryption to obtain the target data to be reported; The target data to be reported is reported to the remote server corresponding to the operating system via a preset network; In response to receiving a data transmission success signal from the remote server, the reporting status of the data to be reported is updated to "successfully reported".

[0012] This application embodiment also provides a monitoring system for a mobile terminal operating system, the monitoring system being equipped with a system event receiver, a system event manager, a missed event detector, a local storage manager, and a batch reporting manager; The system event manager is used to record and broadcast the system event in response to at least one system event occurring in the operating system configured on the target mobile terminal, and to trigger the application performance monitoring service component set by the operating system to initialize each device in the monitoring system. The system event receiver is used to listen to the system events in response to the completion of the initialization of the monitoring system, to identify the pending events in the system events, and to send the event data corresponding to the pending events to the local storage manager. The missed event detector is used to check the system events within the backtracking time window in response to the completion of the initialization of the monitoring system; The local storage manager is used to receive the event data, store the event data in the local database set by the operating system, and organize the event data into data to be reported in the local database. The batch reporting manager is used to periodically retrieve the data to be reported from the local database and report the data to be reported to the remote server corresponding to the operating system via a preset network.

[0013] Furthermore, when the system event receiver and the missed event detector respond to the completion of the monitoring system initialization, listen to the system events, check the system events within the backtracking time window to determine the pending events in the system events, and send the event data corresponding to the pending events to the local storage manager, the system event receiver and the missed event detector are used for: In response to the completion of the initialization of the monitoring system, the system event receiver listens for the system events broadcast by the system event manager, determines the pending events in the system events, and sends the event data corresponding to the pending events to the local storage manager; In response to the completion of the initialization of the monitoring system, the missed event detector checks the system events broadcast by the system event manager within the backtracking time window, and when a missed event is detected, the missed event is sent to the system event receiver; In response to receiving a missed event sent by the missed event detector, the system event receiver determines whether the missed event is an event to be processed, and if the missed event is an event to be processed, sends the event data corresponding to the missed event to the local storage manager.

[0014] Furthermore, when the system event receiver is used to listen for system events broadcast by the system event manager and determine pending events among the system events, the system event receiver is used to: Receive system events broadcast by the system event manager and obtain system information corresponding to each system event; For each system event, based on the system information, a memory deduplication check and a database deduplication check are performed on the system event respectively; When a system event passes the memory deduplication check and the database deduplication check, it is determined whether the system event has been processed. Discard the system event once it has been processed; When a system event is not processed, it is designated as a pending event.

[0015] Furthermore, when the missed event detector is used to respond to the monitoring system completing initialization, check the system events broadcast by the system event manager within the backtracking time window, and send a missed event to the system event receiver upon detection, the missed event detector is used to: In response to the completion of the initialization of the monitoring system, the missed event detector determines the time step corresponding to the backtracking time window based on the current time; The system events broadcast by the system event manager are traversed according to a preset target event type in order to check for any missing events that represent the target event type in the system events; When the omitted event is detected in the system events, a simulated network is constructed and the omitted event is sent to the system event receiver through the simulated network.

[0016] Furthermore, when the local storage manager receives the event data, stores the event data in the local database set by the operating system, and organizes the event data into data to be reported in the local database, the local storage manager is used for: Receive the event data and verify whether the event data meets the preset valid integrity conditions; The event data that meets the valid integrity conditions is stored in the local database set by the operating system; In the local database, data uniqueness constraints corresponding to the event data are generated, and the event data is organized into data to be reported.

[0017] Furthermore, when the local storage manager receives the event data, stores the event data in the local database set by the operating system, and organizes the event data into data to be reported in the local database, the local storage manager is also used for: In response to the stored data to be reported being reported to the remote server by the batch reporting manager, the reported data to be reported is deleted.

[0018] Furthermore, when the batch reporting manager periodically retrieves the data to be reported from the local database and reports the data to be reported to the remote server corresponding to the operating system via a preset network, the batch reporting manager is used for: The data to be reported is periodically retrieved from the local database. The data to be reported is sequentially processed through structured processing and encryption to obtain the target data to be reported; The target data to be reported is reported to the remote server corresponding to the operating system via a preset network; In response to receiving a data transmission success signal from the remote server, the reporting status of the data to be reported is updated to "successfully reported".

[0019] This application embodiment also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the monitoring method of the mobile terminal operating system described above are performed.

[0020] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the monitoring method of the mobile terminal operating system described above.

[0021] This application provides a monitoring method and system for a mobile terminal operating system. The monitoring method is applied to a monitoring system for a mobile terminal operating system. The monitoring system includes a system event receiver, a system event manager, a missed event detector, a local storage manager, and a batch reporting manager. The monitoring method includes: in response to at least one system event occurring in the operating system configured on the target mobile terminal, the system event manager records and broadcasts the system event, and triggers the application performance monitoring service component set by the operating system to initialize each device in the monitoring system; in response to the monitoring system completing initialization, the system event receiver listens for the system event, and the missed event detector checks the system event within a backtracking time window to determine pending events in the system event, and sends the event data corresponding to the pending events to the local storage manager; the local storage manager receives the event data, stores the event data in a local database set by the operating system, and organizes the event data into data to be reported in the local database; the batch reporting manager periodically retrieves the data to be reported from the local database and reports the data to be reported to a remote server corresponding to the operating system via a preset network.

[0022] Compared to existing application performance monitoring technologies that all adopt an application-level monitoring model, which requires integrating specific software development tools into each target application and having the application actively call the interfaces provided by the software development tools to collect performance data during runtime, and then report the data to the server through the application's own network permissions, this new technology improves the completeness and stability of system event monitoring by having the system event receiver listen for system events while the system event manager records and broadcasts system events occurring in the operating system, and the missed event detector checks system events within the backtracking time window. The local storage manager then stores the identified events to be processed locally, and the batch reporting manager periodically retrieves the data to be reported from the local storage and reports it to the remote server. This improves the stability and efficiency of system data processing and reporting.

[0023] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating a monitoring method for a mobile terminal operating system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a monitoring system for a mobile terminal operating system provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments 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. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0027] Research has found that current mainstream Android system application performance monitoring technologies all adopt an application-level monitoring mode. This technology requires the integration of specific software development tools into each target application. When the application runs, it actively calls the interface provided by the software development tool to collect performance data, and then reports the data to the server through the application's own network permissions.

[0028] In the above methods, each application needs to be independently integrated and configured with software development tools, resulting in high deployment costs. It can only monitor applications that have integrated software development tools, and cannot fully grasp the performance status of all applications in the system. The application monitoring coverage is low, and the application program code needs to be modified during deployment, which may also introduce compatibility issues.

[0029] The above methods rely solely on real-time event listening mechanisms. When the monitoring service restarts or becomes temporarily unavailable, critical system events may be missed. Early events may be missed during the initial service startup phase, events generated during system restart cannot be effectively captured, and anomalies occurring during the monitoring service's unavailability cannot be traced, thus reducing the completeness of system event monitoring.

[0030] When the network is unstable or the server fails, data is easily discarded when reporting fails, which reduces the stability of data processing and data reporting. In addition, the above method still performs heavy monitoring operations when the system is busy, which reduces the utilization of system resources.

[0031] Based on this, this application provides a monitoring method for a mobile terminal operating system. When the system event manager records and broadcasts system events occurring in the operating system, the system event receiver listens for system events, while the missed event detector checks system events within the backtracking time window. Then, the local storage manager stores the identified events to be processed locally, and the batch reporting manager periodically retrieves the data to be reported from the local storage and reports it to the remote server. This improves the completeness and stability of system event monitoring, thereby improving the stability and efficiency of system data processing and reporting.

[0032] Please see Figure 1 , Figure 1 This is a flowchart illustrating a monitoring method for a mobile terminal operating system provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the mobile terminal operating system monitoring method is typically applied to a mobile terminal operating system monitoring system; wherein, the monitoring system is equipped with a system event receiver, a system event manager, a missed event detector, a local storage manager, and a batch reporting manager.

[0033] The core functions of the system event receiver are: to listen for system events broadcast by the system event manager, to receive missing events sent by the missing event detector, to perform deduplication verification on the events and determine the events to be processed, and to transfer the event data corresponding to the events to be processed to the local storage manager. In this embodiment, it can be implemented by the "ApmDropBoxReceiver" component, which is the core receiving module of the application performance monitoring service and supports receiving system broadcast and analog broadcast signals.

[0034] The System Event Manager is an event logging and broadcasting component built into the mobile terminal operating system. It is responsible for recording various system events generated during the operation of the operating system in real time (such as application crashes, ANR, system restarts, process freezes, etc.) and sending the recorded events to the internal system in the form of broadcasts for the monitoring system components to receive. It can be implemented in the system through the "DropBoxManager" component, which can continuously record key system events and provide broadcast notification capabilities.

[0035] The Missed Event Detector is used to backtrack and check system events within a specific time window after the monitoring system is initialized, capture events missed due to reasons such as the monitoring service not starting or restarting, and send the missed events to the system event receiver. In this embodiment, it can be implemented by the "MissedEntryChecker" component, which has functions such as event backtracking query and simulated broadcast construction.

[0036] The local storage manager is responsible for receiving event data transmitted by the system event receiver, validating the data, structuring and organizing the data, and providing data retrieval, deletion and integrity assurance functions. In this embodiment, it can be implemented through the "LocalStorageManager" component, relying on the "SQLite" local database to complete persistent data storage.

[0037] The batch reporting manager is responsible for periodically retrieving data to be reported from the local database, processing, encrypting, and reporting the data, and updating the data status and performing retry or cleanup operations based on the reporting results. In this embodiment, it can be implemented through the "BatchReportWorker" component, relying on task scheduling frameworks such as "WorkManager" to trigger periodic tasks.

[0038] like Figure 1 As shown in the embodiments of this application, the method for monitoring the mobile terminal operating system includes: S101. In response to at least one system event occurring in the operating system configured on the target mobile terminal, the system event manager records and broadcasts the system event, and triggers the application performance monitoring service component set by the operating system to initialize each device in the monitoring system.

[0039] It should be noted that the target mobile terminal is a mobile terminal that is expected to perform system stability monitoring through the method described in the embodiments of this application.

[0040] The mobile terminal refers to a portable electronic device carried by the user and possessing computing and communication capabilities. It is mainly used to run applications and access network services. For example, a mobile terminal may include smartphones, tablets, wearable devices, and in-vehicle terminals. The operating system is the core software that manages hardware resources and provides an application running environment, including but not limited to the Android system.

[0041] In this step, when the target mobile terminal's operating system (such as Android, FreemeOS, etc.) experiences system events such as application crashes, application unresponsiveness (ANR), system restarts, process creation / destruction, abnormal battery levels, and network switching, the system event manager first records these system events in real time. The recorded content includes core information such as event type, occurrence timestamp, associated process ID, package name, and event description. Then, the system event manager sends an event addition broadcast according to the operating system's broadcast mechanism. This broadcast is not only used to notify relevant components within the system but also triggers the startup of the operating system's built-in application performance monitoring service component.

[0042] Among them, the Application Performance Monitoring Service (ApmFrameworkService, APM) is used to collect, analyze and display application performance metrics in real time, helping development and operations teams to quickly locate performance bottlenecks, anomalies and faults.

[0043] Here, system events refer to notifications generated by the operating system kernel, system services, or underlying framework that reflect changes in device status or system behavior. These events are different from application-layer interface interaction events (such as clicks and swipes), but are more underlying and global signals, typically used for monitoring, debugging, automation, or system-level function implementation.

[0044] Furthermore, after the application performance monitoring service component starts, the initialization process of the monitoring system is immediately executed, and the system event receiver, the missed event detector, the local storage manager, the batch reporting manager and the system event manager are initialized and configured one by one.

[0045] The initialization of the system event receiver includes registering broadcast listening permissions, starting background processing threads, and initializing memory cache space; the initialization of the missed event detector includes obtaining the system event manager instance and loading the preset event type list; the initialization of the local storage manager includes starting the SQLite database, creating data table structures, and setting data uniqueness constraints; and the initialization of the batch reporting manager includes configuring the task scheduling cycle, initializing network transmission parameters, and setting encryption rules.

[0046] During the initialization process, communication links are established between the components to ensure smooth data transmission. Once all components have been initialized, the monitoring system enters a ready state.

[0047] S102. In response to the completion of the initialization of the monitoring system, the system event receiver listens for the system events, and the missed event detector checks the system events within the backtracking time window to determine the pending events in the system events, and sends the event data corresponding to the pending events to the local storage manager.

[0048] Here, this step is the core process of event capture. By executing real-time monitoring and historical backtracking in parallel, it ensures that no system events are missed. Specifically, it includes the following two parallel branches: event capture and determination of pending events, and backtracking and processing of missed events.

[0049] The events to be processed are system events that have not been processed by the operating system.

[0050] In one possible implementation of this application, step S102 may include: S1021. In response to the completion of the initialization of the monitoring system, the system event receiver listens for the system events broadcast by the system event manager, determines the pending events in the system events, and sends the event data corresponding to the pending events to the local storage manager.

[0051] In this step, after identifying the pending events in the system events, the system event receiver asynchronously transmits the event data corresponding to the pending events to the local storage manager through a background thread to avoid blocking the main thread and affecting the mobile terminal's operating performance. At the same time, it updates the memory cache and stores the unique identifier of the event in the memory cache for subsequent fast deduplication.

[0052] In one possible implementation of this application, step S1021 may include: S10211 The system event receiver receives the system events broadcast by the system event manager and obtains the system information corresponding to each system event.

[0053] In this step, the system information corresponding to each system event is parsed and extracted from the signals corresponding to the system events broadcast by the system event manager, and the obtained data is ensured to be comprehensive and accurate.

[0054] The system information includes, but is not limited to, event tags, timestamps, dropped counts, event content, associated process IDs (pids), user IDs (uids), application package names, process foreground states, and system build information, to ensure that the acquired data is comprehensive and accurate.

[0055] S10212. For each system event, based on the system information, perform memory deduplication checks and database deduplication checks on the system event respectively.

[0056] In this step, for each extracted system event, memory deduplication checks and database deduplication checks are performed based on the above system information to avoid processing the same event repeatedly.

[0057] Among them, memory deduplication check refers to combining the event tag and the timestamp to generate a unique identifier, and querying whether the identifier exists in the memory cache of the system event receiver (the memory cache is used to store recently processed event identifiers and has high-speed query capability).

[0058] Furthermore, if the identifier is not found in the memory cache, a database deduplication check is performed, that is, to check whether there is an event record with the same tag and timestamp in the local database (implemented by relying on the retrieval interface provided by the local storage manager).

[0059] S10213. When the system event passes the memory deduplication check and the database deduplication check, determine whether the system event has been processed.

[0060] S10214. Discard the system event when it has already been processed.

[0061] S10215. When a system event is not processed, the system event is identified as a pending event.

[0062] In this embodiment, if a system event fails the memory deduplication check or the database deduplication check, it means that the event has been processed and is discarded without further operation. If a system event passes both the memory deduplication check and the database deduplication check, it means that the event is a new unprocessed event and is identified as an event to be processed. The extracted system information is then organized into structured event data (encapsulated according to a preset field format for easy storage and subsequent processing).

[0063] S1022. In response to the completion of the initialization of the monitoring system, the missing event detector checks the system events broadcast by the system event manager within the backtracking time window, and when a missing event is detected, the missing event is sent to the system event receiver.

[0064] Here, because the monitoring service may experience startup delays or restarts, some system events may occur before the monitoring service is ready and thus be missed. Therefore, a missed event detector is used for backtracking checks.

[0065] In one possible implementation of this application, step S1022 may include: S10221. In response to the completion of the initialization of the monitoring system, the missed event detector determines the time step corresponding to the backtracking time window based on the current time.

[0066] In this step, after the missed event detector is initialized, the current system time is obtained, and the time step corresponding to the backtracking time window is determined based on the preset rules (usually set to within 5 seconds before the monitoring service starts, which can be adjusted according to actual needs, to ensure coverage of possible missed events, and to avoid excessive resource consumption due to excessive backtracking time, that is, the backtracking time range is: ["current time minus time step", "current time").

[0067] S10222. The system events broadcast by the system event manager are traversed according to the preset target event type to check for missing events that represent the target event type in the system events.

[0068] Here, the target event type may include a key event type, including but not limited to application crash events, application unresponsive events, system restart events, process freeze events, and abnormal battery power events.

[0069] In this step, a preset list of target event types is loaded, which contains the target event types (i.e., critical event types) during the operation of the operating system, to ensure that no core events are missed; then, each target event type is traversed and queried one by one according to the list order.

[0070] S10223. When the omitted event is detected in the system events, a simulation network is constructed and the omitted event is sent to the system event receiver through the simulation network.

[0071] In this step, for each target event type, the system event manager provides an interface to query all system event records of that type within the backtracking time window. Then, the queried event records are compared with the event records already stored in the local database. If an event record does not exist in the local database and is not currently being processed by the system event receiver, then the event is determined to be a missed event.

[0072] Furthermore, when a missed event is detected, the missed event detector constructs a simulated network (simulating the native network format of the system event manager), encapsulates the system information of the missed event into the simulated network, and sends it to the system event receiver through a preset internal communication link to ensure that the missed event can be processed according to the normal event handling process.

[0073] S1023. In response to receiving a missing event sent by the missing event detector, the system event receiver determines whether the missing event is a pending event, and when the missing event is a pending event, sends the event data corresponding to the missing event to the local storage manager.

[0074] In this step, in response to receiving a missing event sent by the missing event detector, the system event receiver repeatedly executes the double deduplication check, pending event judgment and event data transmission steps S10211 to S10215. That is, it determines whether the missing event is a pending event. When the missing event is a pending event, it sends its corresponding event data to the local storage manager.

[0075] Furthermore, if the omitted event has already been processed, then the omitted event is discarded directly.

[0076] In this way, the above process enables unified processing of real-time events and missed events, ensuring the integrity of event capture.

[0077] S103. The local storage manager receives the event data and stores the event data in the local database set by the operating system. In the local database, the event data is organized into data to be reported.

[0078] In this step, after receiving event data transmitted by the system event receiver, the local storage manager performs operations such as data verification, storage, organization, and integrity assurance.

[0079] Here, the local database is a lightweight relational database engine built into the system. It does not require a separate server process and is stored directly on the device as a file. It may include an SQLite database, which is widely used in Android applications to store structured data (such as user configuration, chat history, cache, etc.) and has advantages such as zero configuration, cross-platform compatibility, single file, and ACID transaction support.

[0080] In one possible implementation of this application, step S103 may include: S1031. The local storage manager receives the event data and verifies whether the event data meets the preset valid integrity conditions.

[0081] In this step, the received event data is validated for validity and integrity; that is, the received event data is verified for validity and integrity.

[0082] The valid integrity conditions include, but are not limited to, data format conforming to preset specifications, field values ​​being valid (such as whether the timestamp is a valid integer, whether the process ID exists, etc.), and core fields (such as event tags, timestamps, event content, etc.) being complete.

[0083] Furthermore, if the data does not meet the preset valid integrity conditions, the data is discarded directly and a verification failure log is recorded; if the data meets the conditions, the next storage process is initiated.

[0084] S1032. Store the event data that meets the valid integrity conditions in the local database set by the operating system.

[0085] In this step, the verified event data is stored in the local database built into the operating system. For example, the local database used in this application embodiment is an SQLite database, which has the characteristics of being lightweight, efficient, and supporting local persistent storage.

[0086] For example, the default fields in the local database table structure include: id: primary key, auto-incrementing integer; tag: event tag, text type; timestamp: timestamp, integer type; content: event content and text type; dropped_count: drop count, integer type; parsed_process: parsed process name, text type; parsed_pid: parsed process ID, text type; parsed_uid: parsed user ID, text type; parsed_frozen: parsed frozen state, text type; parsed_flags: parsed flags, text type; parsed_package_name: parsed package name, text type; parsed_foreground: parsed foreground state, text type; parsed_build: parsed build information, text type.

[0087] S1033. In the local database, generate data uniqueness constraints corresponding to the event data, and organize the event data into data to be reported.

[0088] In this step, uniqueness constraints are set for the data table in the local database. This involves creating a unique index using the (tag, timestamp) field combination to ensure that event data with the same tag and timestamp are not inserted into the database repeatedly, thereby enhancing the data deduplication effect and avoiding the storage of redundant data.

[0089] Furthermore, the local storage manager organizes the event data stored in the database according to the reporting requirements, generating data to be reported.

[0090] The data processing includes, but is not limited to, field filtering (retaining the core fields required for reporting and removing redundant parsing fields), data formatting (converting data into formats that are easy to transmit over the network, such as JSON), and status marking (marking each piece of data as "pending reporting" and storing it in the status field of the data table).

[0091] Here, after the data has been processed, the data to be reported is in a state that can be retrieved by the batch reporting manager.

[0092] Optionally, in another possible implementation of this application, step S103 further includes: S1034. In response to the storage of the data to be reported being reported to the remote server by the batch reporting manager, the local storage manager deletes the reported data to be reported.

[0093] In this embodiment of the application, the local storage manager also has a data cleanup trigger function, that is, in response to the successful reporting of the stored data to be reported to the remote server by the batch reporting manager, the reported data is immediately deleted from the local database to release storage space and avoid the database from occupying too much mobile terminal storage resources.

[0094] For data that fails to be reported, it remains in the "pending report" state and waits for the next report attempt.

[0095] S104. The batch reporting manager periodically retrieves the data to be reported from the local database and reports the data to be reported to the remote server corresponding to the operating system through a preset network.

[0096] In one possible implementation of this application, step S104 may include: S1041. The batch reporting manager periodically retrieves the data to be reported from the local database.

[0097] In this step, the batch reporting manager relies on the operating system's task scheduling framework (such as WorkManager in Android) to start reporting tasks according to a preset cycle (which can be adjusted according to the mobile terminal usage scenario, such as once every 30 minutes, or triggered when the system is idle), so as to avoid frequent reporting occupying network and system resources.

[0098] Furthermore, the batch reporting manager uses the retrieval interface provided by the local storage manager to query all data with a status of "pending reporting" in the local database, i.e., data to be reported.

[0099] Here, to avoid conflicts during data transmission, the data is temporarily locked after acquisition, preventing the local storage manager from modifying or deleting it.

[0100] S1042. The data to be reported is sequentially processed by structuring and encryption to obtain the target data to be reported.

[0101] In this step, the acquired data to be reported is sequentially processed through structured processing and encryption to obtain the target data to be reported.

[0102] The structured processing includes data format validation, field completion (filling in missing non-core fields with default values), and data compression (using compression algorithms such as GZIP to reduce data size and improve transmission efficiency); the encryption processing uses preset encryption rules (such as AES encryption algorithm) to encrypt the data to ensure the security of the data during network transmission and prevent the data from being stolen or tampered with.

[0103] S1043. The target data to be reported is reported to the remote server corresponding to the operating system through a preset network.

[0104] In this step, the batch reporting manager sends the encrypted target data to be reported to the remote server corresponding to the operating system via a preset network (such as a mobile data network or a Wi-Fi network).

[0105] Here, during the reporting process, the network connection status is monitored in real time. If the network is interrupted, the reporting is paused and transmission continues after the network is restored.

[0106] S1044. In response to receiving a data transmission success signal sent by the remote server, update the reporting status of the data to be reported to "successfully reported".

[0107] In this step, the batch reporting manager receives a response signal from the remote server. If a data transmission success signal is received, it indicates that the data has been successfully reported. The local storage manager is immediately notified to unlock the data, update the data status to "reported", and trigger the local storage manager to delete the data. If a data transmission failure signal is received, or no response signal is received within a preset time, the reporting is determined to have failed. The data is unlocked, and the data is kept in the "pending reporting" state, waiting to be retried when the next reporting task is triggered.

[0108] Here, the number of retries can be preset (e.g., a maximum of 3 retries). After the number of retries is exceeded, a failure log is recorded and the issue is handled manually.

[0109] Based on this, the mobile terminal operating system monitoring method provided in this application combines real-time monitoring and historical backtracking to ensure that no system events are missed, thus achieving completeness in monitoring system events; it employs a dual deduplication mechanism of memory caching and database uniqueness constraints to avoid redundant processing and achieve efficient deduplication of event data; it ensures that data is not lost through local persistent storage and intelligent retry mechanisms, thus achieving reliable reporting of event data; and it reduces the impact on system performance through intelligent task scheduling based on system status.

[0110] The mobile terminal operating system monitoring method provided in this application improves the integrity and stability of system event monitoring by having a system event receiver listen to system events while the system event manager records and broadcasts system events occurring in the operating system, and a missed event detector checks system events within the backtracking time window. Then, the local storage manager stores the identified events to be processed locally, and the batch reporting manager periodically retrieves the data to be reported from the local storage and reports it to the remote server. This improves the stability and efficiency of system event monitoring, thereby improving the stability and efficiency of system data processing and reporting.

[0111] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of a monitoring system for a mobile terminal operating system provided in an embodiment of this application. Figure 2 As shown, the monitoring system 200 is equipped with a system event receiver 220, a system event manager 210, a missed event detector 230, a local storage manager 240, and a batch reporting manager 250; The system event manager 210 is used to record and broadcast the system event in response to at least one system event occurring in the operating system configured on the target mobile terminal, and to trigger the application performance monitoring service component set by the operating system to initialize each device in the monitoring system 200. The system event receiver 220 is used to listen to the system events in response to the completion of the initialization of the monitoring system 200, to determine the pending events in the system events, and to send the event data corresponding to the pending events to the local storage manager 240. The missing event detector 230 is used to check the system events within the backtracking time window in response to the initialization of the monitoring system 200. The local storage manager 240 is used to receive the event data, store the event data in the local database set by the operating system, and organize the event data into data to be reported in the local database. The batch reporting manager 250 is used to periodically retrieve the data to be reported from the local database and report the data to be reported to the remote server corresponding to the operating system through a preset network.

[0112] Furthermore, when the system event receiver 220 and the missed event detector 230 respond to the monitoring system 200 completing initialization, listen to the system events, check the system events within the backtracking time window to determine the pending events in the system events, and send the event data corresponding to the pending events to the local storage manager 240, the system event receiver 220 and the missed event detector 230 are used to: In response to the completion of initialization of the monitoring system 200, the system event receiver 220 listens for the system events broadcast by the system event manager 210, determines the pending events in the system events, and sends the event data corresponding to the pending events to the local storage manager 240; In response to the completion of initialization of the monitoring system 200, the missing event detector 230 checks the system events broadcast by the system event manager 210 within the backtracking time window, and when a missing event is detected, the missing event is sent to the system event receiver 220; In response to receiving a missed event sent by the missed event detector 230, the system event receiver 220 determines whether the missed event is an event to be processed, and when the missed event is an event to be processed, sends the event data corresponding to the missed event to the local storage manager 240.

[0113] Furthermore, when the system event receiver 220 is used to listen for system events broadcast by the system event manager and determine pending events among the system events, the system event receiver 220 is used to: Receive system events broadcast by the system event manager 210, and obtain system information corresponding to each system event; For each system event, based on the system information, a memory deduplication check and a database deduplication check are performed on the system event respectively; When a system event passes the memory deduplication check and the database deduplication check, it is determined whether the system event has been processed. Discard the system event once it has been processed; When a system event is not processed, it is designated as a pending event.

[0114] Furthermore, when the missed event detector 230 responds to the monitoring system 200 completing initialization, checks the system events broadcast by the system event manager 210 within the backtracking time window, and sends a missed event to the system event receiver 220 upon detection of a missed event, the missed event detector 230 is used to: In response to the completion of initialization of the monitoring system 200, the missed event detector 230 determines the time step corresponding to the backtracking time window based on the current time; The system events broadcast by the system event manager 210 are traversed according to a preset target event type to check for any missing events that represent the target event type in the system events; When the omitted event is detected in the system events, a simulated network is constructed and the omitted event is sent to the system event receiver 220 through the simulated network.

[0115] Furthermore, when the local storage manager 240 receives the event data, stores the event data in the local database set by the operating system, and organizes the event data into data to be reported in the local database, the local storage manager 240 is used for: Receive the event data and verify whether the event data meets the preset valid integrity conditions; The event data that meets the valid integrity conditions is stored in the local database set by the operating system; In the local database, data uniqueness constraints corresponding to the event data are generated, and the event data is organized into data to be reported.

[0116] Furthermore, when the local storage manager 240 receives the event data, stores the event data in the local database set by the operating system, and organizes the event data into data to be reported in the local database, the local storage manager 240 is also used for: In response to the stored data to be reported being reported to the remote server by the batch reporting manager 250, the reported data to be reported is deleted.

[0117] Furthermore, when the batch reporting manager 250 periodically retrieves the data to be reported from the local database and reports the data to be reported to the remote server corresponding to the operating system via a preset network, the batch reporting manager 250 is used for: The data to be reported is periodically retrieved from the local database. The data to be reported is sequentially processed through structured processing and encryption to obtain the target data to be reported; The target data to be reported is reported to the remote server corresponding to the operating system via a preset network; In response to receiving a data transmission success signal from the remote server, the reporting status of the data to be reported is updated to "successfully reported".

[0118] The mobile terminal operating system monitoring system provided in this application improves the integrity and stability of system event monitoring by having a system event receiver listen to system events while the system event manager records and broadcasts system events occurring in the operating system, and a missed event detector checks system events within the backtracking time window. Then, the local storage manager stores the identified events to be processed locally, and the batch reporting manager periodically retrieves the data to be reported from the local storage and reports it to the remote server. This improves the stability and efficiency of system event monitoring, thereby improving the stability and efficiency of system data processing and reporting.

[0119] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 300 includes a processor 310, a memory 320, and a bus 330.

[0120] The memory 320 stores machine-readable instructions executable by the processor 310. When the electronic device 300 is running, the processor 310 and the memory 320 communicate via the bus 330. When the machine-readable instructions are executed by the processor 310, they can perform the operations described above. Figure 1 The steps of the mobile terminal operating system monitoring method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0121] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the mobile terminal operating system monitoring method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0122] Those skilled in the art will 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.

[0123] 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. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0124] 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.

[0125] In addition, 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.

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

[0127] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, 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, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for monitoring a mobile terminal operating system, characterized in that, The monitoring method is applied to a monitoring system of a mobile terminal operating system; wherein, the monitoring system is equipped with a system event receiver, a system event manager, a missed event detector, a local storage manager, and a batch reporting manager, and the monitoring method includes: In response to at least one system event occurring in the operating system configured on the target mobile terminal, the system event manager records and broadcasts the system event, and triggers the application performance monitoring service component set by the operating system to initialize each device in the monitoring system; In response to the completion of the initialization of the monitoring system, the system event receiver listens for the system events, and the missed event detector checks the system events within the backtracking time window to determine the pending events in the system events, and sends the event data corresponding to the pending events to the local storage manager. The local storage manager receives the event data and stores it in the local database set by the operating system. In the local database, the event data is organized into data to be reported. The batch reporting manager periodically retrieves the data to be reported from the local database and reports the data to be reported to the remote server corresponding to the operating system via a preset network.

2. The method according to claim 1, characterized in that, In response to the completion of the monitoring system initialization, the system event receiver listens for system events, and the missed event detector checks the system events within the backtracking time window to identify pending events among the system events. The event data corresponding to the pending events is then sent to the local storage manager, including: In response to the completion of the initialization of the monitoring system, the system event receiver listens for the system events broadcast by the system event manager, determines the pending events in the system events, and sends the event data corresponding to the pending events to the local storage manager; In response to the completion of the initialization of the monitoring system, the missed event detector checks the system events broadcast by the system event manager within the backtracking time window, and when a missed event is detected, the missed event is sent to the system event receiver; In response to receiving a missed event sent by the missed event detector, the system event receiver determines whether the missed event is an event to be processed, and if the missed event is an event to be processed, sends the event data corresponding to the missed event to the local storage manager.

3. The method according to claim 2, characterized in that, The process of the system event receiver listening to the system events broadcast by the system event manager and determining the pending events among the system events includes: The system event receiver receives the system events broadcast by the system event manager and obtains the system information corresponding to each system event; For each system event, based on the system information, a memory deduplication check and a database deduplication check are performed on the system event respectively; When a system event passes the memory deduplication check and the database deduplication check, it is determined whether the system event has been processed. Discard the system event once it has been processed; When a system event is not processed, it is designated as a pending event.

4. The method according to claim 2, characterized in that, The response to the monitoring system completing initialization includes the omission event detector checking the system events broadcast by the system event manager within the backtracking time window, and upon detecting a missed event, sending the missed event to the system event receiver, including: In response to the completion of the initialization of the monitoring system, the missed event detector determines the time step corresponding to the backtracking time window based on the current time; The system events broadcast by the system event manager are traversed according to a preset target event type in order to check for any missing events that represent the target event type in the system events; When the omitted event is detected in the system events, a simulated network is constructed and the omitted event is sent to the system event receiver through the simulated network.

5. The method according to claim 1, characterized in that, The process involves the local storage manager receiving the event data, storing the event data in a local database set by the operating system, and organizing the event data into data to be reported in the local database, including: The local storage manager receives the event data and verifies whether the event data meets the preset valid integrity conditions. The event data that meets the valid integrity conditions is stored in the local database set by the operating system; In the local database, data uniqueness constraints corresponding to the event data are generated, and the event data is organized into data to be reported.

6. The method according to claim 5, characterized in that, The step of receiving the event data from the local storage manager, storing the event data in the local database set by the operating system, and organizing the event data into data to be reported in the local database also includes: In response to the batch reporting manager reporting the data to be reported to the remote server, the local storage manager deletes the reported data to be reported.

7. The method according to claim 1, characterized in that, The step of periodically retrieving the data to be reported from the local database by the batch reporting manager and reporting the data to be reported to the remote server corresponding to the operating system via a preset network includes: The batch reporting manager periodically retrieves the data to be reported from the local database; The data to be reported is sequentially processed through structured processing and encryption to obtain the target data to be reported; The target data to be reported is reported to the remote server corresponding to the operating system via a preset network; In response to receiving a data transmission success signal from the remote server, the reporting status of the data to be reported is updated to "successfully reported".

8. A monitoring system for a mobile terminal operating system, characterized in that, The monitoring system is equipped with a system event receiver, a system event manager, a missed event detector, a local storage manager, and a batch reporting manager; The system event manager is used to record and broadcast the system event in response to at least one system event occurring in the operating system configured on the target mobile terminal, and to trigger the application performance monitoring service component set by the operating system to initialize each device in the monitoring system. The system event receiver is used to listen to the system events in response to the completion of the initialization of the monitoring system, to identify the pending events in the system events, and to send the event data corresponding to the pending events to the local storage manager. The missed event detector is used to check the system events within the backtracking time window in response to the completion of the initialization of the monitoring system; The local storage manager is used to receive the event data, store the event data in the local database set by the operating system, and organize the event data into data to be reported in the local database. The batch reporting manager is used to periodically retrieve the data to be reported from the local database and report the data to be reported to the remote server corresponding to the operating system via a preset network.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the monitoring method of the mobile terminal operating system as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the monitoring method of the mobile terminal operating system as described in any one of claims 1 to 7.

Images