Log printing method and related device

By configuring log printing rules and paths in electronic devices, the memory waste and positioning difficulty caused by redundancy in log content in electronic devices is solved, and customized log printing and storage of business modules is realized.

CN117707439BActive Publication Date: 2025-08-29HONOR DEVICE CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202311061359.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-08-22
Publication Date
2025-08-29
Estimated Expiration
2043-08-22

AI Technical Summary

Technical Problem

During the operation of each business module in electronic devices, there are a lot of log content printed, including information that is unrelated to problem positioning, which leads to waste of memory resources and increased difficulty in positioning problems.

Method used

By configuring log printing rules and paths in the configuration file of the business module, electronic devices can independently print and store logs of each business module according to the rules, realizing customized log printing.

Benefits of technology

It realizes independent printing and storage of flow logs of each business module, reduces the waste of memory resources, reduces the difficulty of positioning problems, and provides personalized customized services.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117707439B_ABST
    Figure CN117707439B_ABST
Patent Text Reader

Abstract

The log printing method and related device provided in the embodiments of the present application relate to the field of terminal technology. The method includes: when a business module needs to locate a problem, the business module can configure log printing rules in the configuration file of the business module, and can also configure a log printing path. The electronic device can print relevant logs for the business module according to the log printing rules, and print the logs of the business module separately according to the log printing path configured by the business module. In this way, the log of each business module can be printed and saved independently, thereby realizing customized log printing for each business module.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to a log printing method and related devices. Background Art

[0002] Each business module in the electronic device can print logs during operation, and developers can locate problems based on the logs printed by each business module.

[0003] However, the logs contain a lot of content, which may include some logs that are irrelevant to the problem location of a certain business module, thereby causing a waste of memory resources and increasing the difficulty of locating the problem of the business module. Summary of the Invention

[0004] The log printing method and related device provided by the embodiments of the present application enable the module to configure log printing rules and a log printing path in its configuration file when a problem needs to be located. The electronic device can then print relevant logs for the module based on the log printing rules and print the logs of the module separately based on the log printing path configured for the module. This allows the logs of each module to be printed and saved independently, thus enabling customized log printing for each module.

[0005] In a first aspect, the log printing method provided by the embodiment of the present application includes:

[0006] A first process is running in a first electronic device, and the first electronic device launches a first disk process, and the first disk process is used to print the log of the first process in a first file path, wherein the first process is configured with a first log rule file, and the parameters in the first log rule file include: the name of the first process and the first file path; a second process is running in the first electronic device, and the first electronic device launches a second disk process, and the second disk process is used to print the log of the second process in a second file path, wherein the second process is configured with a second log rule file, and the parameters in the second log rule file include: the name of the second process and the second file path, the first process is different from the second process, and the first file path is different from the second file path; a third process is running in the first electronic device, and the first electronic device prints the log of the third process in a third file path, wherein the third process is not configured with a log rule file; a fourth process is running in the first electronic device, and the first electronic device prints the log of the fourth process in the third file path, wherein the fourth process is not configured with a log rule file, and the third process is different from the fourth process. In this way, the log of each process can be printed and saved independently, thereby realizing customized log printing for each process.

[0007] In one possible implementation, the first log rule file includes log interception rule parameters and log storage rule parameters. The log interception rule parameters include one or more of the following: log label setting parameters, single log print length setting parameters, and log flow setting parameters. The log storage rule parameters include the name of the first process and the first file path. The log storage rule parameters also include one or more of the following: maximum output log file size, maximum number of compressed log files, log compression mode, log reading method, and log reading path. In this way, each business module can modify the log printing rules of its own process as needed, thereby achieving independent printing and storage of logs for each business module, providing personalized customization services.

[0008] In one possible implementation, before the first electronic device starts the first disk-writing process, the following steps are further included: the first electronic device determines that the first process is configured with a first log rule file, and the first electronic device obtains the log of the first process from the log buffer of the logd module; the first electronic device stores the log of the first process in the log file cache pool; after the first electronic device starts the first disk-writing process, the following steps are further included: the first disk-writing process obtains the log of the first process from the log file cache pool; the first disk-writing process prints the log of the first process in the first file path. In this way, by printing logs according to the log-writing rules, the logs of each business module can be written to different output file directories, thereby realizing independent printing and storage of the logs of each business module, and providing a convenient log printing method for each business module.

[0009] In a possible implementation, the control log xlogcat process of the first electronic device includes a target logcat process, the target logcat process is used to obtain the log of the first process from the log buffer of the logd module, and print the log of the first process in the first file path, the first electronic device obtains the log of the first process from the log buffer of the logd module, including: the target logcat process calls the logger_read interface and the logd_reader interface for obtaining the log, and obtains the log of the first process from the log buffer of the logd module through the socket channel; the first electronic device prints the log of the first process The logs are stored in a log file cache pool, including: a target logcat process stores the logs of a first process in the log file cache pool; a first electronic device launches a first disk write process, including: a log control xlogcat process launches the first disk write process; the first disk write process obtains the logs of the first process from the log file cache pool, including: the first disk write process polls the log file cache pool based on an interface provided by the target logcat process to obtain the logs of the first process; the first disk write process prints the logs of the first process in a first file path, including: the first disk write process prints the logs of the first process in the first file path based on the interface provided by the target logcat process. In this way, the first electronic device can conveniently read the logs of the first process by calling the relevant interface, thereby realizing log reading and write to disk.

[0010] In one possible implementation, the method further includes: when the first process is running on the first electronic device, the first electronic device intercepts logs of the first process, and the first electronic device stores the intercepted logs in a log buffer of a logd module. In this way, the first process can print required logs according to business needs, providing a convenient log interception method for the first process.

[0011] In one possible implementation, the first electronic device intercepts the log of the first process, including: the first electronic device performs a first-level interception on the log of the first process, wherein the first-level interception includes one or more of the following: verifying the printing format of the log of the first process, intercepting the level of the log of the first process, judging the buffer where the log of the first process is stored, and adding a timestamp to the log of the first process; the first electronic device performs a second-level interception on the log of the first process based on the log interception rule parameters, wherein the second-level interception includes one or more of the following: labeling the log of the first process according to the log label setting parameters set by the first process, limiting the length of a single log of the first process according to the print length of a single log set by the first process, and limiting the length of the log printed per second by the first process according to the log flow set by the first process. In this way, after the log information of the first process undergoes two log interceptions, more useful log information can be filtered for the first process, thereby improving the efficiency of locating problems in the first process and improving the user experience.

[0012] In one possible implementation, the first electronic device performs a first-level interception on the log of the first process, including: the first electronic device calls the logger_write interface to perform a first-level interception on the log of the first process; the first electronic device performs a second-level interception on the log of the first process based on the log interception rule parameters, including: the first electronic device calls the logd_wirter interface to perform a second-level interception on the log of the first process based on the log interception rule parameters; the first electronic device stores the intercepted log in the log buffer of the logd module, including: the first electronic device stores the intercepted log in the log buffer of the logd module through a socket channel. In this way, by calling the logger_write interface and the logd_wirter interface related to log writing, it is convenient to intercept the date information of the first process during the process of saving the log of the first process, thereby saving information that is more useful for locating problems in the first process.

[0013] In one possible implementation, before the first electronic device determines that the first process is configured with the first log rule file, the process further includes: the first electronic device receiving an upgrade package from the second electronic device, the upgrade package including the first log rule file for the first process; and the first electronic device parsing the first log rule file for the first process from the upgrade package. In this way, by pushing the upgrade package from the cloud, each business module can dynamically configure the log rule file based on business needs, modify log parameters at any time, and achieve flexible log printing, thereby improving the scalability of log printing.

[0014] In one possible implementation, the first electronic device sends the log of the first process to the second electronic device. In this way, developers can analyze the log through the big data website of the second electronic device, thereby improving the efficiency of problem analysis and resolution.

[0015] In a second aspect, an embodiment of the present application provides a device for log printing, which may be an electronic device or a chip or chip system within an electronic device. The device may include a processing unit. The processing unit is used to implement any method related to processing performed by the electronic device in the first aspect or any possible implementation of the first aspect. When the device is an electronic device, the processing unit may be a processor. The device may also include a storage unit, which may be a memory. The storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit to enable the electronic device to implement the method described in the first aspect or any possible implementation of the first aspect. When the device is a chip or chip system within an electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit to enable the electronic device to implement the method described in the first aspect or any possible implementation of the first aspect. The storage unit may be a storage unit within the chip (for example, a register, a cache, etc.), or it may be a storage unit within the electronic device located outside the chip (for example, a read-only memory, a random access memory, etc.).

[0016] Exemplarily, the processing unit is used to run the first process and also to pull up the first disk process; it is also used to run the second process and also to pull up the second disk process; it is also used to run the third process and also to print the log of the third process in the third file path; it is also used to run the fourth process and also to print the log of the fourth process in the third file path.

[0017] In one possible implementation, the first log rule file includes: log interception rule parameters and log disk transfer rule parameters. The log interception rule parameters include one or more of the following: log label setting parameters, single log print length setting parameters, and log flow setting parameters; the log disk transfer rule parameters include: the name of the first process and the first file path. The log disk transfer rule parameters also include one or more of the following: the maximum capacity of the output log file, the maximum number of compressed log files, the log compression mode, the log reading method, and the path for reading the log.

[0018] In one possible implementation, the processing unit is used to determine whether the first process is configured with a first log rule file, and is also used to obtain the log of the first process from the log buffer of the logd module, and is also used to store the log of the first process in the log file cache pool; specifically, it is also used to obtain the log of the first process from the log file cache pool, and is also used to print the log of the first process in the first file path.

[0019] In one possible implementation, the processing unit is used to call the logger_read interface and the logd_reader interface for obtaining logs, and is also used to obtain the log of the first process from the log buffer of the logd module through the socket channel; is also used to store the log of the first process in the log file cache pool; is also used to pull up the first disk process; is also used to poll the log file cache pool based on the interface provided by the target logcat process to obtain the log of the first process, and specifically is also used to print the log of the first process in the first file path based on the interface provided by the target logcat process.

[0020] In a possible implementation, the processing unit is configured to intercept the log of the first process, and further configured to store the intercepted log in a log buffer of the logd module.

[0021] In a possible implementation, the processing unit is configured to perform a first-level interception on the log of the first process, and is further configured to perform a second-level interception on the log of the first process based on log interception rule parameters.

[0022] In one possible implementation, the processing unit is used to call the logger_write interface to perform the first-level interception on the log of the first process, and is also used to call the logd_wirter interface to perform the second-level interception on the log of the first process based on the log interception rule parameters, and is specifically used to store the intercepted log in the log buffer of the logd module through the socket channel.

[0023] In a possible implementation, the processing unit is configured to receive an upgrade package from the second electronic device, and further configured to parse the upgrade package to obtain a first log rule file of the first process.

[0024] In a possible implementation, the processing unit is configured to send a log of the first process to the second electronic device.

[0025] In a third aspect, an embodiment of the present application provides a terminal device, comprising a processor and a memory, wherein the memory is used to store code instructions, and the processor is used to run the code instructions to execute the method described in the first aspect or any possible implementation of the first aspect.

[0026] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program or instruction is stored. When the computer program or instruction is run on a computer, the computer executes the method described in the first aspect or any possible implementation of the first aspect.

[0027] In a fifth aspect, an embodiment of the present application provides a computer program product comprising a computer program, which, when the computer program runs on a computer, enables the computer to execute the method described in the first aspect or any possible implementation of the first aspect.

[0028] In a sixth aspect, the present application provides a chip or chip system, comprising at least one processor and a communication interface, wherein the communication interface and the at least one processor are interconnected via a line, and the at least one processor is configured to execute a computer program or instruction to perform the method described in the first aspect or any possible implementation of the first aspect. The communication interface in the chip may be an input / output interface, a pin, or a circuit.

[0029] In one possible implementation, the chip or chip system described above in this application further includes at least one memory, in which instructions are stored. The memory may be a storage unit within the chip, such as a register, a cache, etc., or a storage unit of the chip (e.g., a read-only memory, a random access memory, etc.).

[0030] It should be understood that the second to sixth aspects of the present application correspond to the technical solutions of the first aspect of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0032] Figure 2 A schematic diagram of the software structure of an electronic device provided in an embodiment of the present application;

[0033] Figure 3 A schematic diagram of the overall architecture of a log printing method provided in an embodiment of the present application;

[0034] Figure 4 A diagram illustrating the interaction between business modules for log interception and log storage provided in an embodiment of the present application;

[0035] Figure 5 A schematic diagram of a log printing method provided in an embodiment of the present application;

[0036] Figure 6A schematic diagram of the structure of a chip provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] To facilitate a clear description of the technical solutions of the embodiments of the present application, some of the terms and technologies involved in the embodiments of the present application are briefly introduced below:

[0038] 1. Log level: Log levels from low to high include: Verbos level, Debug level, Info level, Warn level, and Error level.

[0039] Verbos level: The Verbos level is low and can be used to print more detailed information while the process is running.

[0040] Debug level: The Debug level can be used to print some running information of the process. Logs at this level can be used by developers to debug and sort out processes. The official version does not print such logs.

[0041] Info level: The Info level can be used to print some important information when the process is running, which helps developers track the process execution flow and log the key links in the process execution flow, so as to restore the main execution flow of the process.

[0042] Warn level: The Warn level is used to print information about potential errors that may occur during process execution. Warn level logs indicate unexpected exceptions and are logged when exceptions are caught. Warn level logs have minimal impact on users and can be automatically recovered from.

[0043] Error level: Error level logs can be used to print errors and exceptions that occur during process execution. Error level logs indicate that a user-perceivable exception has occurred and cannot be automatically recovered.

[0044] 2. Terminology

[0045] In the embodiments of this application, terms such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. For example, the terms "first chip" and "second chip" are used solely to distinguish between different chips and do not define their order. Those skilled in the art will understand that terms such as "first" and "second" do not define the quantity or execution order, and do not necessarily define differences.

[0046] It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this application as "exemplary" or "for example" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0047] In the embodiments of the present application, "at least one" refers to one or more, and "more" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, c can be single or multiple.

[0048] 3. Electronic devices

[0049] The electronic device of the embodiment of the present application may also be a terminal device in any form. For example, the electronic device may include: a mobile phone, a tablet computer, a PDA, a laptop computer, a mobile internet device (MID), a wearable device, a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with wireless communication function, a computing device or other processing device connected to a wireless modem, an in-vehicle device, a wearable device, an electronic device in a 5G network or a future evolved public land mobile communication network (PLMN) Mobile network, PLMN) and other electronic devices, and the embodiments of the present application are not limited to this.

[0050] As an example and not a limitation, in the embodiments of the present application, the electronic device may also be a wearable device. Wearable devices may also be referred to as wearable smart devices, which are a general term for wearable devices that are intelligently designed and developed using wearable technology for daily wear, such as glasses, gloves, watches, clothing, and shoes. A wearable device is a portable device that is worn directly on the body or integrated into the user's clothes or accessories. Wearable devices are not only hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are fully functional, large in size, and can achieve complete or partial functions without relying on smartphones, such as smart watches or smart glasses, as well as those that only focus on a certain type of application function and need to be used in conjunction with other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0051] In addition, in the embodiment of the present application, the electronic device can also be an electronic device in the Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection.

[0052] The electronic devices in the embodiments of the present application may also be referred to as: user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent or user device, etc.

[0053] In the embodiments of the present application, the electronic device or each network device includes a hardware layer, an operating system layer running on the hardware layer, and an application layer running on the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory (also known as main memory). The operating system can be any one or more computer operating systems that implement business processing through processes, such as a Linux operating system, a Unix operating system, an Android operating system, an iOS operating system, or a Windows operating system. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software.

[0054] For example, Figure 1 A schematic structural diagram of an electronic device is shown.

[0055] The electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0056] It is understood that the structures illustrated in the embodiments of the present invention do not constitute specific limitations on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The components shown in the diagram may be implemented in hardware, software, or a combination of software and hardware.

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

[0058] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0059] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0060] In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a SIM card interface, and / or a USB interface.

[0061] It is understood that the interface connection relationship between the modules illustrated in the embodiments of the present invention is only a schematic illustration and does not constitute a structural limitation of the electronic device. In other embodiments of the present application, the electronic device may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0062] The internal memory 121 can be used to store computer executable program code, and the executable program code includes instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area can store data created during the use of the electronic device (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device by running instructions stored in the internal memory 121, and / or instructions stored in a memory provided in the processor. For example, the method of an embodiment of the present application can be executed.

[0063] Figure 2 This is a block diagram of the software structure of the electronic device in an embodiment of the present application. The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into five layers: the application layer, the application framework layer, the Android runtime and system library, the hardware abstraction layer (HAL), and the kernel layer.

[0064] The application layer can also be called the application layer, which can include a series of application packages. Figure 2 As shown, the application package may include applications (APPs) such as phone, music, calendar, camera, game, memo, video, etc. Applications may include system applications and third-party applications.

[0065] The application framework layer provides an application programming interface (API) and programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0066] like Figure 2 As shown, the application framework layer may include a window manager, a resource manager, a content provider, a view system, etc. The application framework layer may also provide a related log interface for the application layer's application program to print logs.

[0067] The window manager is used to manage window programs. The window manager can obtain the display size, determine whether there is a status bar, lock the screen, touch the screen, drag the screen, take screenshots, etc.

[0068] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0069] Content providers are used to implement data sharing between different applications, allowing one program to access data in another while ensuring the security of the accessed data.

[0070] The view system is responsible for drawing the application interface and handling events.

[0071] The Android runtime includes the core library and the virtual machine. The Android runtime is responsible for controlling and managing the Android system.

[0072] The core library consists of two parts: one is the function that needs to be called by the Java language, and the other is the Android core library.

[0073] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files in the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection. For example, in the embodiments of the present application, the virtual machine can be used to perform functions such as log collection, log interception, and log storage.

[0074] The system library can also be called the Native layer, which can include multiple functional modules. For example, in the embodiment of the present application, the Native layer can include: a log interception module, an extensible markup language (XML) parsing module, a logd module, a logcat module, function libraries, etc.

[0075] The log interception module can be used to intercept output logs according to log rules.

[0076] The XML parsing module can be used to parse the log rules configured in the XML file.

[0077] The logd module may include a logd process of the log system, which may be used to manage and store logs during the operation of the Android system.

[0078] On the one hand, the logd process can implement functions such as reading, writing, and controlling log information through the socket interface. For example, the socket logd can be used to transmit control instructions, the socket logdw can be used to write logs, and the socket logdr can be used to read logs. The socket interface can also be understood as a socket channel.

[0079] On the other hand, the logd process can be used to store various logs in the Android system. The buffers for storing logs can include the main buffer, system buffer, crash buffer, and events buffer. The main buffer can be used to store application-generated log information, the system buffer can be used to store system messages and debug log information, the crash buffer can be used to store abnormal event log information, and the events buffer can be used to store system event log information. The buffer where the logd module stores logs is also called the log buffer.

[0080] The logcat module may include a logcat process, which may be understood as a log viewing service process provided by the Android system. For example, the logcat process may display log information on a console.

[0081] The function library provides developers with API interfaces for multiple services, making it easy for developers to quickly integrate and implement various functions.

[0082] The Hardware Abstraction Layer (HAL) is an abstracted layer between the kernel layer and the Android runtime. It encapsulates hardware drivers, providing a unified interface for upper-layer applications. For example, in this embodiment, the HAL can encapsulate the logging module and provide a logging-related interface for the native layer.

[0083] The kernel layer is the layer between hardware and software. The kernel layer may include display drivers, camera drivers, audio drivers, battery drivers, Bluetooth drivers, CPU drivers, USB drivers, etc. In the embodiment of the present application, the kernel layer may also include a kernel log module.

[0084] It should be noted that the embodiments of the present application are only illustrated using the Android system as an example. In other operating systems (such as Windows system, IOS system, etc.), as long as the functions implemented by each functional module are similar to those in the embodiments of the present application, the solutions of the present application can also be implemented.

[0085] During operation, electronic devices can print maintenance and testing logs. These logs may include logs printed to the log buffer by various business modules, kernel logs, and the electronic device's voltage and / or current logs. Business modules may include applications (APPs) and service programs (Services).

[0086] It can be understood that the logs printed by each business module to the log buffer can also be called running logs. The running logs can include logs printed by Android's log system and logs printed by the log system developed by the developer. Each business module can locate problems based on the running logs.

[0087] However, since each business module can call the public interface provided by the electronic device to print logs, the logbook includes log information printed by each business module. As a result, the logbook contains a lot of content and may include logs that are irrelevant to the problem location of a certain business module, resulting in a waste of memory resources and increasing the difficulty of locating the problem of the business module.

[0088] In view of this, the log printing method provided in the embodiments of the present application allows, when a business module needs to locate a problem, the business module to configure log printing rules and a log printing path in its configuration file. The electronic device can then print relevant logs for the business module according to the log printing rules and print the logs of the business module separately according to the log printing path configured for the business module. In this way, the logs of each business module can be printed and saved independently, thereby achieving customized log printing for each business module.

[0089] In a possible implementation, the electronic device may set log printing permissions for each service module, including setting a default log printing level for each service module. For example, the default log printing level may be Error level and above. In addition, the electronic device may also set the printing of logs of certain system services, which may also be referred to as public logs.

[0090] Figure 3 The overall structure of the log printing method of the embodiment of the present application is shown.

[0091] The overall architecture involves (1) a cloud server and (2) electronic devices. The cloud server can also be called the cloud side, and the electronic devices can also be called the end side.

[0092] (1) Cloud side.

[0093] The cloud side can execute the following processes: (1.1) the cloud side obtains the log rule file, (1.2) the cloud side packages the log rule file and generates an upgrade package, (1.3) the cloud side pushes the upgrade package to the end side, and (1.4) the cloud side receives the logs uploaded by the end side.

[0094] (1.1) The cloud side obtains the log rule file.

[0095] The cloud side can periodically call the relevant interface to obtain the log rule files configured by each business module on the end side. Among them, the log rule file can also be called a configuration file. The specific period for the cloud side to obtain the log rule file can be customized by the cloud side and is not limited by the embodiments of this application.

[0096] It is understandable that when a service module in an electronic device needs to locate a problem, the service module can configure a log interception rule in the log rule file of the service module. The log rule file can include a file in XML format, for example, the log rule file can be an aplog_control_config.xml file.

[0097] In a possible implementation, the log interception rules may include log tag setting parameters, setting of the print length of a single log entry, setting of log flow, etc.

[0098] The log label setting parameters may include the class name, function name, variable name, etc. in the business module. The specific log label setting parameters can be customized by the business module, and the embodiments of the present application are not limited thereto. The business module configuration log label setting parameters may also include setting whitelist labels and / or blacklist labels. Exemplarily, if the business module sets a whitelist label, the electronic device may print log information related to the whitelist label when the business module is running; if the business module sets a blacklist label, the electronic device may not print log information related to the blacklist label when the business module is running. It is understandable that if the business module does not set the log label setting parameters, the electronic device may print all log information when the business module is running.

[0099] The business module also allows you to set the maximum length of a single log print. Limiting the log length can reduce the probability of abnormalities in the log system and save memory space resources.

[0100] Log traffic can be understood as the length of logs printed per second by an electronic device. It's understandable that by limiting the length of logs printed per second, the business module can minimize the system load on the electronic device, thereby reducing the impact of log printing on the electronic device's performance and power consumption.

[0101] (1.2) The cloud side packages the log rule files and generates an upgrade package.

[0102] After the cloud side obtains the log rule files configured for each business module, it can package the log rule files for each business module to generate an upgrade package. It is understandable that since the upgrade package includes the log rule parameters configured for each business module, the upgrade package can also be called a parameter upgrade package.

[0103] (1.3) The cloud side pushes the upgrade package to the client side.

[0104] In one possible implementation, the cloud side can regularly push upgrade packages to the client side through a push server, which can also be called a push server. The specific period of pushing upgrade packages from the cloud side to the client side can be customized by the cloud side and is not limited by the embodiments of this application.

[0105] In another possible implementation, when a business module on the client side has a need, such as when a business module needs to obtain logs according to configured log printing rules to locate a problem, or when a module needs to upgrade its version, the developer can operate on the cloud side to push the upgrade package to the client side through the push server. For example, the developer can turn on the switch for pushing upgrade packages on the cloud side, thereby enabling the cloud side to push the upgrade package to the client side.

[0106] It is understandable that the cloud side can push the upgrade package to the end side in any possible way. The specific implementation method of the cloud side pushing the upgrade package to the end side is not limited in this embodiment of the application.

[0107] (1.4) The cloud side receives the logs uploaded by the client side.

[0108] After generating logs for each business module on the client side, the client can upload them to a big data website on the cloud side. Based on the uploaded logs, the big data website can analyze, locate, and optimize issues in each business module, thereby improving the user experience.

[0109] (2) End side.

[0110] The end side can execute the following process: (1.1) The end side downloads the upgrade package and parses the log rule file, (1.2) The end side starts the process according to the log rule, (1.3) The end side collects logs, and (1.4) The end side uploads the logs to the cloud side.

[0111] (1.1) The client downloads the upgrade package and parses the log rule file.

[0112] After receiving the push message from the cloud, the client can download the upgrade package pushed by the cloud and parse the upgrade package to extract the log rule files configured for each business module. The client can parse the upgrade package in any feasible manner. The specific method for parsing the upgrade package is not limited in this embodiment of the application.

[0113] (1.2) The client starts the process based on the log rules.

[0114] The client can determine the corresponding business module based on the parsed log rule files. For example, the log rule file can include the name of the business module, and the client can use this to identify the corresponding business module. This allows the client to determine which business modules are configured with log rule files and write logs to disk based on the log rule files.

[0115] For example, assuming that a log rule file is configured for process A, the client can launch a disk-based process A1 while process A is running. This disk-based process A1 can be used to obtain log information from process A during its execution and store it separately, allowing the log information of process A to be stored separately from the log information of other business modules on the client. This allows the log information of process A to be stored separately from the log information of other business modules on the client. Because the logs of process A do not include the logs of other business modules, when process A needs to troubleshoot a problem, it can obtain logs related to process A, reducing the difficulty of troubleshooting the problem for process A.

[0116] (1.3) Log collection is performed on the client side.

[0117] On the one hand, the log collection on the terminal side may include obtaining relevant parameters for log interception according to the log interception rules configured for each business module, and intercepting the log information generated by each business module according to these parameters.

[0118] On the other hand, the end-side log collection can also include the end-side log storage of each business module. The specific end-side log interception and log storage process will be described in the following Figure 4 The corresponding embodiments are described in detail and will not be repeated here.

[0119] (1.4) The client uploads logs to the cloud.

[0120] After logs for each business module are written to disk, the client-side maintenance and testing service can regularly upload these logs to the cloud-side big data website. This allows developers to analyze the logs on the big data website, improving the efficiency of problem analysis and resolution.

[0121] Figure 4 This diagram shows the business module interaction diagram for log interception and log storage by the terminal-side maintenance and testing service.

[0122] The client can run multiple processes, including Figure 4 The following uses process 1 as an example to illustrate the process of log interception and log storage by the maintenance service.

[0123] (1) Log interception.

[0124] When process 1 needs to print a log, it can call a log writing interface. For example, the log writing interface may include the logger_write interface. The logger_write interface can be used to initialize the logd module, verify the validity of process 1's log information, and add a timestamp to the log. Validity verification can include verifying the log printing format, intercepting the log level, and determining the log storage buffer.

[0125] For example, the logger_write interface can verify the format of log printing. If the content does not conform to the log printing format, it may not be printed in the log. Verifying the log printing format can correctly output log information, improve the readability of the log, and facilitate problem location.

[0126] Log level interception can be understood as the logger_write interface intercepting logs by controlling the log printing level. For example, when the client-side log level is set to Debug, all process logs at Debug, Info, Warn, Error, and above are printed. When the client-side log level is set to Info, all process logs at Info, Warn, Error, and above are printed, but Debug logs are not printed. When the client-side log level is set to Error, all process logs at Error and above are printed, but Debug, Info, and Warn logs are not printed.

[0127] Log storage buffers can include the main buffer, system buffer, crash buffer, and events buffer. The client can determine in which buffer the process log information is stored.

[0128] In addition, the client can also add timestamps to the process log information. This allows developers to easily find log information around the time when the problem occurred, reducing the difficulty of problem location.

[0129] After performing the above-mentioned processing on the log information of process 1, the logger_write interface can send the processed log information of process 1 to the logd_wirter interface. The logd_wirter interface can then store the log information of process 1 in the log buffer of the logd module through the socket channel. It is understood that the logd_wirter interface can include a log interception module, which can be used to intercept the log information output by process 1 according to the log printing rules configured by process 1. Among them, the log interception module can also be called a private log interception module.

[0130] (2) Logs are written to disk.

[0131] After parsing the log rule file for process 1, the client uses the xlogcat process to read process 1's logs from the logd module's log buffer and store them in the log file cache pool. Furthermore, the client uses the xlogcat process to start process 1, which writes the logs from the log file cache pool to disk.

[0132] It's understood that the xlogcat process can also be referred to as the log management xlogcat process. The xlogcat process can be used to manage and control log-related processes. For example, the xlogcat process can manage the target logcat process and the process that writes to disk. For example, the xlogcat process can start or stop the target logcat process or the process that writes to disk. The target logcat process can read logs from the logd module's log buffer and compress logs into files for storage on the client's hard drive.

[0133] In a possible implementation, when the xlogcat process reads the logs of process 1 from the logd module's log buffer, it can call a log reading interface based on the target logcat process. For example, the log reading interface can include the logger_read interface. The logger_read interface can further call the logd_reader interface, which can obtain the logs of process 1 from the logd module's log buffer via a socket channel. The target logcat process can store the logs of process 1 separately in the log file cache pool, thereby distinguishing and saving the logs of process 1 from the logs of other business modules on the client side.

[0134] When process 1 writes its logs to disk, it can poll and read the logs of process 1 from the log file cache pool based on the target logcat process, and write the logs of process 1 to disk separately according to the log writing rules configured in the log rule file by process 1, thereby generating a compressed file of the logs of process 1 and realizing independent printing and storage of the logs of process 1.

[0135] It can be understood that the log disk transfer rules may include the name of the business module, the chip platform of the business module, the maximum capacity of the output log file, the maximum number of compressed log files, the log compression mode, the log reading method, the path for reading the log, the log compression disk transfer path, etc.

[0136] Taking process 1 as an example, the business module name of the log disk rule may include the process name of process 1 or the process identification (PID) of process 1, etc., which is not limited in the embodiment of the present application.

[0137] The chip platform of the business module can be configured by process 1, and the embodiment of the present application does not limit the chip platform of the business module.

[0138] The maximum capacity of the output log file can be customized by process 1. For example, the maximum capacity of the output log file can be set to 4096Kbytes, which is not limited in this embodiment of the present application.

[0139] The maximum number of compressed log files can be customized by process 1. For example, the maximum number of compressed log files can be set to 20, which is not limited in this embodiment of the present application.

[0140] Log compression modes can include factory mode and stream compression mode. Factory mode can be understood as first writing process 1's log to disk and then compressing the written log of process 1. Stream compression mode can be understood as first compressing process 1's log and then writing the compressed log of process 1 to disk. The log compression mode can be customized by process 1 and is not limited in this embodiment of the application.

[0141] The log reading method may include a polling method (poll_node) and a monitor method (monitor_node). It is understood that if process 1 uses the polling method to read the log, process 1 can set the interval for polling the log, for example, the interval for polling the log can be set to 10 milliseconds, which is not limited in the embodiments of the present application.

[0142] Process 1 can set the path for reading logs. In this way, the log compression process of the maintenance and testing service can determine where to read the logs of process 1 based on the path for reading logs set by process 1.

[0143] Process 1 can also set the log compression disk path, for example, process 1 can set the log compression disk path to Figure 4 It is understandable that different business modules can set different log compression disk paths, which is not limited in this embodiment of the present application.

[0144] The client-side maintenance and testing application can obtain the logs from OutputPath1, the compressed log storage path for process 1, and regularly upload the logs to the cloud-side big data website. This allows developers to analyze the logs on the big data website, improving the efficiency of problem analysis and resolution.

[0145] It is understandable that the process of log printing and log storage in the embodiment of the present application is different from the process of log printing and storage of kernel logs. Kernel log printing can be achieved by writing logs to the file dev / kmsg in a write node manner through the printk function, while kernel log storage can be achieved by calling the xlogcat service to read the dev / kmsg node file for log storage.

[0146] It is understandable that the log printing method of the embodiment of the present application can also be applied to fault management scenarios. In some implementations, when a fault event occurs in a business module on the end side, the business module can send fault management information to the cloud side. The fault management information may include: fault event, business module name, fault time point, etc. Developers can find logs near the fault time point in the log stream uploaded on the end side based on the fault management information and locate the problem. However, such a problem locating process is relatively complicated, and the log stream includes a lot of redundant information, which is not conducive to developers to locate the problem.

[0147] In this embodiment of the present application, the service module on the client side can dynamically configure a log rule file based on the cloud side. When a failure occurs in a service module on the client side, the client side can generate a log related to the service module around the time of the failure based on the log rule file. This allows the client to obtain logs related to the service module without the redundant information often found in log files, thus reducing the difficulty of problem locating.

[0148] The following describes the method of the embodiment of the present application in detail through specific embodiments. The following embodiments can be combined with each other or implemented independently, and the same or similar concepts or processes may not be repeated in some embodiments.

[0149] Figure 5 The log printing method of an embodiment of the present application is shown. The method includes:

[0150] S501: A first process is running in a first electronic device. The first electronic device starts a first disk-writing process, and the first disk-writing process is used to print a log of the first process in a first file path. The first process is configured with a first log rule file, and parameters in the first log rule file include: a name of the first process and a first file path.

[0151] In the embodiment of the present application, the first electronic device may be any terminal device, for example, the electronic device may include a mobile phone, a tablet or other electronic device.

[0152] The first process can be understood as any process running in the first electronic device. For example, the first process can be a process of an application in the first electronic device, or a process of a system service in the first electronic device, which is not limited in the embodiment of the present application.

[0153] The first file path can be understood as the path for printing the first process log, and the first file path can also be understood as the log compression and disk path in the above embodiment.

[0154] The first log rule file can be understood as a log rule file configured by the first process.

[0155] S502: A second process is running in the first electronic device. The first electronic device starts a second disk-dropping process. The second disk-dropping process is used to print a log of the second process in a second file path. The second process is configured with a second log rule file. The parameters in the second log rule file include: a name of the second process and a second file path. The first process and the second process are different, and the first file path and the second file path are different.

[0156] In the embodiment of the present application, the second process can be understood as any process running in the first electronic device. The second file path can be understood as the path for printing the second process log. The second log rule file can be understood as the log rule file configured by the second process.

[0157] S503: A third process is running in the first electronic device, and the first electronic device prints a log of the third process in a third file path, wherein the third process is not configured with a log rule file.

[0158] In the embodiment of the present application, the third process can be understood as any process running in the first electronic device. The third file path can be understood as the path for printing the third process log.

[0159] S504: A fourth process is running in the first electronic device, and the first electronic device prints a log of the fourth process in the third file path. The fourth process is not configured with a log rule file, and the third process is different from the fourth process.

[0160] In the embodiment of the present application, the fourth process can be understood as any process running in the first electronic device. The fourth file path can be understood as the path for printing the fourth process log.

[0161] It can be understood that the first process, the second process, the third process and the fourth process can be run synchronously or asynchronously in the first electronic device, and there is no limit on the running time. The embodiments of the present application do not limit the running time of the first process, the second process, the third process and the fourth process.

[0162] In the embodiment of the present application, each process can be configured with its own log printing rules and log printing paths. The electronic device can print logs for each process according to the log printing rules and print logs for each process separately according to the log printing paths. In this way, the logs of each process can be printed and saved independently, thereby achieving customized log printing for each process.

[0163] Optional, in Figure 5Based on the corresponding embodiment, the first log rule file may include: log interception rule parameters and log disk rule parameters. The log interception rule parameters include one or more of the following: log label setting parameters, single log printing length setting parameters, and log flow setting parameters; the log disk rule parameters include: the name of the first process and the first file path. The log disk rule parameters also include one or more of the following: the maximum capacity of the output log file, the maximum number of compressed log files, the log compression mode, the log reading method, and the path for reading the log.

[0164] In the embodiment of the present application, the log interception rules and related parameters can refer to the above Figure 3 The description of the log interception rules in the corresponding embodiment will not be repeated here. The log storage rules and related parameters can be referred to above. Figure 4 The description of the log storage rules in the corresponding embodiment will not be repeated here.

[0165] The first process can modify the first log rule file as needed. Similarly, each business module can modify the log printing rules of its own process as needed, thereby achieving independent printing and saving of logs of each business module and providing personalized customization services.

[0166] Optional, in Figure 5 On the basis of the corresponding embodiment, before the first electronic device starts the first disk landing process, it may also include: the first electronic device determines that the first process is configured with a first log rule file, and the first electronic device obtains the log of the first process from the log buffer of the log logd module; the first electronic device stores the log of the first process in the log file cache pool; after the first electronic device starts the first disk landing process, it may also include: the first disk landing process obtains the log of the first process from the log file cache pool; the first disk landing process prints the log of the first process in the first file path.

[0167] In the embodiment of the present application, the first electronic device obtains the log of the first process from the log buffer of the logd module and stores it in the log file cache pool, and the first disk process obtains the log of the first process from the log file cache pool and prints the log of the first process in the first file path. The process can refer to the above Figure 4 The relevant description of the corresponding embodiment (2) of storing logs on disk is omitted here.

[0168] Print logs according to the log storage rules. The logs of each business module can be stored in different output file directories, thereby realizing independent printing and storage of logs of each business module, providing a convenient log printing method for each business module.

[0169] Optional, in Figure 5On the basis of the corresponding embodiment, the control log xlogcat process of the first electronic device includes a target logcat process, the target logcat process is used to obtain the log of the first process from the log buffer of the logd module, and print the log of the first process in the first file path. The first electronic device obtains the log of the first process from the log buffer of the logd module, which can include: the target logcat process calls the logger_read interface and the logd_reader interface for obtaining the log, and obtains the log of the first process from the log buffer of the logd module through the socket channel; the first electronic device prints the log of the first process Storing into the log file cache pool may include: the target logcat process storing the log of the first process into the log file cache pool; the first electronic device pulling up the first disk writing process may include: the control log xlogcat process pulling up the first disk writing process; the first disk writing process obtaining the log of the first process from the log file cache pool may include: the first disk writing process polling and obtaining the log of the first process from the log file cache pool based on the interface provided by the target logcat process; the first disk writing process printing the log of the first process in the first file path may include: the first disk writing process printing the log of the first process in the first file path based on the interface provided by the target logcat process.

[0170] In the embodiment of this application, the specific process of log storage can refer to the above Figure 4 The relevant description of the corresponding embodiment (2) of writing logs to disk is omitted here. The relevant interface called by the first electronic device can conveniently read the logs of the first process, thereby realizing the reading and writing of the logs to disk.

[0171] Optional, in Figure 5 Based on the corresponding embodiment, the method may further include: when a first process is running in the first electronic device, the first electronic device intercepts the log of the first process, and the first electronic device stores the intercepted log in a log buffer of the logd module.

[0172] In the embodiment of the present application, the first electronic device intercepts the log of the first process and stores the intercepted log in the log buffer of the logd module. Figure 4 The relevant description in the corresponding embodiment (1) log interception is not repeated here.

[0173] Printing logs according to log interception rules allows the first process to print required logs according to business needs. For example, the first process can print logs related to problem location, thereby providing a convenient log interception method for the first process.

[0174] Optional, in Figure 5On the basis of the corresponding embodiment, the first electronic device intercepts the log of the first process, which may include: the first electronic device performs a first-level interception on the log of the first process, wherein the first-level interception includes one or more of the following: verifying the printing format of the log of the first process, intercepting the level of the log of the first process, judging the buffer where the log of the first process is stored, and adding a timestamp to the log of the first process; the first electronic device performs a second-level interception on the log of the first process based on the log interception rule parameters, and the second-level interception includes one or more of the following: labeling the log of the first process according to the log label setting parameters set by the first process, limiting the length of a single log of the first process according to the printing length of a single log set by the first process, and limiting the length of the log printed per second by the first process according to the log traffic set by the first process.

[0175] In the embodiment of the present application, the first electronic device intercepts the log of the first process at the first level, which can be understood as the interception of the log of the first process by the electronic device when the first process calls the logger_write interface for writing logs. Figure 4 The relevant description in the corresponding embodiment (1) log interception is not repeated here.

[0176] The second level of interception can be understood as the interception of the log of the first process by the first electronic device based on the log interception rule parameters. The second level of interception can also be understood as the above Figure 4 The interception of the process by the log interception module of the logd_wirter interface in the corresponding embodiment (1) log interception is not described in detail.

[0177] The log information of the first process is intercepted twice, so that more useful log information can be filtered for the first process, thereby improving the efficiency of locating problems in the first process and improving user experience.

[0178] Optional, in Figure 5 On the basis of the corresponding embodiment, the first electronic device performs a first-level interception on the log of the first process, which may include: the first electronic device calls the logger_write interface to perform a first-level interception on the log of the first process; the first electronic device performs a second-level interception on the log of the first process based on the log interception rule parameters, which may include: the first electronic device calls the logd_wirter interface to perform a second-level interception on the log of the first process based on the log interception rule parameters; the first electronic device stores the intercepted log in the log buffer of the logd module, which may include: the first electronic device stores the intercepted log in the log buffer of the logd module through the socket channel.

[0179] In the embodiment of the present application, the process of the first electronic device intercepting the log of the first process can refer to the above Figure 4 The relevant description in the corresponding embodiment (1) log interception is not repeated here.

[0180] By calling the logger_write interface and the logd_wirter interface related to log writing, the date information of the first process can be intercepted in the process of saving the log of the first process, thereby saving more useful information for locating problems in the first process.

[0181] Optional, in Figure 5 On the basis of the corresponding embodiment, before the first electronic device determines that the first process is configured with the first log rule file, it may also include: the first electronic device receives an upgrade package from the second electronic device, and the upgrade package includes the first log rule file of the first process; the first electronic device parses the first log rule file of the first process from the upgrade package.

[0182] In the embodiment of the present application, the second electronic device may be an electronic device that can transmit the upgrade package to the first electronic device. For example, the second electronic device may include a cloud server, which is not limited in the embodiment of the present application.

[0183] The interaction between the first electronic device and the second electronic device can refer to the above Figure 3 The relevant description of the corresponding embodiment (1) in the cloud side is not repeated here. By pushing the upgrade package on the cloud side, each business module can dynamically configure the log rule file according to business needs, modify the log parameters at any time, and realize flexible printing of logs, thereby improving the expansion capability of log printing.

[0184] Optional, in Figure 5 On the basis of the corresponding embodiment, the first electronic device sends the log of the first process to the second electronic device.

[0185] In the embodiment of the present application, the first electronic device sending the log of the first process to the second electronic device can be understood as the process of the maintenance application of the first electronic device uploading the log to the big data website of the second electronic device. Figure 3 The relevant description in the corresponding embodiment (1.4) of uploading logs from the end side to the cloud side is not repeated here.

[0186] Through the big data website of the second electronic device, developers can analyze logs to improve the efficiency of problem analysis and resolution.

[0187] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0188] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of method. In order to realize the above functions, it includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily appreciate that, in combination with the method steps of each example described in the embodiment disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software driven hardware manner depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0189] The embodiment of the present application can divide the functional modules of the device implementing the method according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. In actual implementation, there may be other division methods.

[0190] like Figure 6 FIG. 6 is a schematic diagram of a chip structure provided by an embodiment of the present application. The chip 600 includes one or more (including two) processors 601 , a communication line 602 , a communication interface 603 , and a memory 604 .

[0191] In some implementations, the memory 604 stores the following elements: executable modules or data structures, or a subset thereof, or an extended set thereof.

[0192] The method described in the above embodiment of the present application can be applied to the processor 601, or implemented by the processor 601. The processor 601 may be an integrated circuit chip with signal processing capabilities. During the implementation process, each step of the above method can be completed by an integrated logic circuit of the hardware in the processor 601 or an instruction in the form of software. The above-mentioned processor 601 can be a general-purpose processor (for example, a microprocessor or a conventional processor), a digital signal processor (digital signal processing, DSP), an application specific integrated circuit (application specific integrated circuit, ASIC), a field-programmable gate array (field-programmable gate array, FPGA) or other programmable logic devices, discrete gates, transistor logic devices or discrete hardware components. The processor 601 can implement or execute the methods, steps and logic block diagrams related to each processing disclosed in the embodiment of the present application.

[0193] The steps of the method disclosed in the embodiments of the present application can be directly implemented as being executed by a hardware decoding processor, or can be implemented by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as a random access memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable read-only memory (EEPROM). The storage medium is located in the memory 604, and the processor 601 reads the information in the memory 604 and completes the steps of the above method in combination with its hardware.

[0194] The processor 601 , the memory 604 , and the communication interface 603 can communicate with each other via the communication line 602 .

[0195] In the above embodiment, the instructions stored in the memory for execution by the processor may be implemented in the form of a computer program product, wherein the computer program product may be pre-written in the memory or downloaded and installed in the memory in the form of software.

[0196] The present application also provides a computer program product including one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated. For example, the available medium can include magnetic media (e.g., floppy disk, hard disk or tape), optical media (e.g., digital versatile disc (DVD)), or semiconductor media (e.g., solid state disk (SSD)).

[0197] The present application also provides a computer-readable storage medium. The methods described in the above embodiments can be implemented in whole or in part via software, hardware, firmware, or any combination thereof. Computer-readable media can include computer storage media and communication media, and can also include any medium that can transfer a computer program from one location to another. The storage medium can be any target medium that can be accessed by a computer.

[0198] As one possible design, computer-readable media may include compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM, or other optical disc storage; computer-readable media may include magnetic disk storage or other magnetic disk storage devices. Moreover, any connecting line may also be appropriately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks typically reproduce data magnetically, while discs reproduce data optically using lasers.

[0199] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processing unit of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

Claims

1. A log printing method, characterized in that: The method comprises: A first process is running in the first electronic device, and the control log xlogcat process of the first electronic device includes a target logcat process; The first electronic device receives an upgrade package from the second electronic device, the upgrade package including a first log rule file for the first process; parameters in the first log rule file include: log interception rule parameters and log disk write rule parameters, the log interception rule parameters include one or more of the following: log label setting parameters, single log print length setting parameters, and log flow setting parameters; the log disk write rule parameters include: the name of the first process and a first file path, and the log disk write rule parameters also include one or more of the following: maximum capacity of an output log file, maximum number of compressed log files, log compression mode, log reading method, and log reading path; Parsing, by the first electronic device, the first log rule file of the first process from the upgrade package; The first electronic device determines that the first process is configured with the first log rule file, the target logcat process calls the logger_read interface and the logd_reader interface for obtaining logs, and obtains the log of the first process from the log buffer of the logd module through the socket channel; The target logcat process stores the log of the first process in the log file buffer pool; The log control xlogcat process starts a first disk writing process, which polls the log file cache pool to obtain the log of the first process based on the interface provided by the target logcat process, and prints the log of the first process in the first file path based on the interface provided by the target logcat process; A second process is running in the first electronic device, the first electronic device launches a second disk-writing process, and the second disk-writing process is used to print a log of the second process in a second file path, wherein the second process is configured with a second log rule file, and parameters in the second log rule file include: a name of the second process and the second file path, the first process and the second process are different, and the first file path and the second file path are different; A third process is running in the first electronic device, and the first electronic device prints a log of the third process in a third file path, wherein the third process is not configured with a log rule file; A fourth process is running in the first electronic device, and the first electronic device prints a log of the fourth process in the third file path, wherein the fourth process is not configured with the log rule file, and the third process is different from the fourth process; The method further comprises: The first electronic device performs a first-level interception on the log of the first process, wherein the first-level interception includes one or more of the following: verifying a print format of the log of the first process, intercepting a level of the log of the first process, determining a buffer where the log of the first process is stored, and adding a timestamp to the log of the first process; The first electronic device performs a second-level interception on the log of the first process based on the log interception rule parameters, and the second-level interception includes one or more of the following: labeling the log of the first process according to the log label setting parameters set by the first process, limiting the length of a single log print of the first process according to the single log print length set by the first process, and limiting the length of the log printed per second by the first process according to the log traffic set by the first process.

2. The method according to claim 1, characterized in that The first electronic device performs a first-level interception on the log of the first process, including: The first electronic device calls the logger_write interface to perform the first layer interception on the log of the first process; The first electronic device performs a second-layer interception on the log of the first process based on the log interception rule parameter, including: The first electronic device calls the logd_wirter interface to perform the second-layer interception on the log of the first process based on the log interception rule parameters; The first electronic device stores the intercepted log in the log buffer of the logd module, including: The first electronic device stores the intercepted log in the log buffer of the logd module through the socket channel.

3. The method according to claim 1 or 2, characterized in that The first electronic device sends the log of the first process to the second electronic device.

4. An electronic device, characterized in that: include: A memory and a processor, the memory being used to store a computer program, and the processor being used to execute the computer program to perform the method according to any one of claims 1 to 3.

5. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, which, when executed, enable a computer to perform the method according to any one of claims 1 to 3.

6. A computer program product, characterized in that The invention comprises a computer program, which, when being executed, enables the electronic device to perform the method according to any one of claims 1 to 3.

Citation Information

Patent Citations

  • Method for storage event log to automatically filter repeated jitter data

    CN103164511A

  • Method for writing transaction logs in database in parallel to improve processing efficiency

    CN114116665A

  • Log reading method, server, computer equipment and storage medium

    CN114756435A