Log reporting method and system and electronic equipment

Abstract

The invention provides a log reporting method and system and electronic equipment. In the scheme of the invention, the first device is a master device, is in master-slave communication with at least one second device, and is also in communication with the third device with a log file collection function. When the first device determines that the third device requests the file information of the second compressed log file in the target second device (which is one of the at least one second device), the first device executes master-slave switching, so that the target second device is switched into the master device to communicate with the third device. And after the target second equipment communicates with the third equipment, the file information of the second compressed log file is sent to the third equipment, and the third equipment carries out reporting interaction of the second compressed log file with the target second equipment according to the received file information. According to the scheme, master-slave switching is introduced, so that the slave device can directly report the log file in the slave device to the third device, the original master device is not needed, and the log reporting process of the slave device can be effectively reduced.

Description

Technical Field

[0001] This application relates to the technical field of data transmission, and particularly to a log reporting method, system, and electronic device Background Art

[0002] With the popularization of rich devices such as mobile phones, various other products that communicate with rich devices for cooperative use, such as thin devices like earphones and watches, have emerged in an endless stream. To provide high-quality product services to users, currently, most thin devices have the ability to report logs, and the log reporting process is as follows: When problems such as lags occur during the use of a thin device, the user can operate the rich device to trigger a problem feedback for the thin device; in response to the triggered problem feedback, the rich device will synchronously request the thin device to report logs, and after the rich device is connected to the network, it will package the log file reported by the thin device and the log file of the rich device together and report them to the server, so that the R & D personnel of the thin device can view and analyze the problem logs through the corresponding website to respond to and solve the problems feedback by the users

[0003] However, in the above log reporting process, in the scenario where the thin device includes a master device and a slave device, the log file of the slave device needs to be obtained by the master device and reported to the rich device. Compared with the log reporting of the master device, the log reporting of the slave device has problems such as complex reporting processes and overly long required time. In addition, the existing log reporting of thin devices also has problems such as overly large log files, slow reporting speeds, and packet loss during log reporting Summary of the Invention

[0004] In view of the above problems, multiple aspects of this application provide a log reporting method, system, and electronic device to achieve the purpose of simplifying the log reporting process of the slave device for master-slave devices, and further to achieve the effects of reducing the size of the log report, increasing the log reporting speed, and reducing the log packet loss rate. Thus,

[0005] In the first embodiment of this application, a log reporting method is provided, which is applicable to a first device. The first device communicates with at least one second device as a master-slave device and also communicates with a third device with a specific log file collection function. The log reporting method includes:

[0006] When it is detected that the condition for reporting the log file to the third device is met, a log file list is generated according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device

[0007] The log file list is sent to the third device

[0008] In response to the file information acquisition request sent by the third device according to the log file list, the file name specified by the request is determined

[0009] If the specified file name contains the device identifier of the target second device, perform master-slave switching with the target second device so that the target second device switches to the master device to communicate with the third device, and send the file information of the second compressed log file in the target second device to the third device, so that the third device performs the sub-packet collection operation of the second compressed log file on the target second device according to the received file information; wherein, the target second device is one of the at least one second device.

[0010] In the second embodiment of the present application, a log reporting method is further provided, which is applicable to a target second device, and the target second device is one of at least one second device; the at least one second device is a slave device and communicates with the first device in a master-slave manner. The log reporting method includes:

[0011] Receive the reporting status notification sent by the first device and the communication connection information between the first device and the third device; wherein, the reporting status notification is used to inform that the current log file reporting status is the file information to be reported status;

[0012] Save the current log file reporting status;

[0013] Establish a communication connection with the third device according to the communication connection information;

[0014] After establishing a communication connection with the third device, according to the saved current log file reporting status, send the file information of the second compressed log file in the target second device to the third device, so that the third device performs the sub-packet collection operation of the second compressed log file on the target second device according to the received file information;

[0015] Wherein, the communication connection information is sent when the first device performs master-slave switching with the target second device in the case that the file name specified in the received file information acquisition request contains the device identifier of the target second device; the file information acquisition request is sent by the third device to the first device according to the received log file list; the log file list is generated by the first device according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device and sent to the third device; after the target second device establishes a communication connection with the third device, the device role status of the target second device switches from a slave device to a master device, and the third device disconnects the communication connection with the first device.

[0016] In the third embodiment of the present application, a log reporting method is further provided, which is applicable to a third device. The log reporting method includes:

[0017] Display an interactive interface;

[0018] In response to an operation triggered by the user through the interactive interface, send a log file list acquisition request to a first device selected by the user for which log reporting is required;

[0019] According to the log file list fed back by the first device received, send a file information acquisition request to the first device;

[0020] In response to a communication connection request sent by a target second device, establish a communication connection with the target second device and disconnect the communication connection with the first device;

[0021] Receive file information of a second compressed log file in the target second device sent by the target second device;

[0022] According to the file information of the second compressed log file and log file transmission parameters, perform a sub-packet collection operation on the second compressed log file of the target second device;

[0023] Wherein, the first device performs master-slave communication with at least one second device, and the log file list is generated by the first device according to the file names of first compressed log files in the first device and the file names of second compressed log files in the at least one second device; the target second device is one of the at least one second devices; the target second device sends a communication connection request to a third device according to communication connection information of the first device sent and received with the third device; the first device sends the communication connection information to the target second device when performing master-slave switching with the target second device in the case that it is determined that the file name specified in the received file information acquisition request carries the device identifier of the target second device.

[0024] In a fourth embodiment of the present application, a log reporting method applicable to a first device is further provided. The log reporting method includes:

[0025] Receive a log data acquisition request sent by a third device for a first compressed log file in the first device; wherein, the log data acquisition request carries the start offset, data size, and frame log bitmap of the target packet log data requested; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or indicates that all frame logs in the target packet log data need to be uploaded;

[0026] According to the start offset and the data size, acquire the target packet log data from the multi-packet log data included in the first compressed log file;

[0027] If the frame log bit map indicates that some frame logs in the target packet log data need to be retransmitted, determine the frame numbers of the frame logs to be retransmitted according to the frame log bit map; according to the frame numbers and the negotiated frame length, selectively retransmit multiple frame logs in the target packet log data to the third device;

[0028] If the frame log bit map indicates that all frame logs in the target packet log data need to be uploaded, transmit multiple frame logs in the target packet log data to the third device frame by frame.

[0029] In the fifth embodiment of the present application, a log reporting method is further provided, which is applicable to a first device. The first device is communicatively connected to a third device, and the third device has a log file collection function. The log reporting method includes:

[0030] Obtain the logs generated by the application on the first device;

[0031] Perform hash processing on the logs generated by the application to obtain the hashed logs;

[0032] Write the hashed logs into the log file corresponding to the application;

[0033] When it is detected that the condition for reporting the log file to the third device is met, compress all the log files in the first device together to obtain a first compressed log file;

[0034] Send the file information of the first compressed log file to the third device for the third device to perform sub-packet collection operations on the first compressed log file of the first device according to the file information.

[0035] In the sixth embodiment of the present application, a log reporting system is further provided. The system includes:

[0036] A third device with a log file collection function;

[0037] At least one second device;

[0038] A first device communicatively connected to the third device and master-slave communicatively connected to the at least one second device. In the master-slave communication connection, the first device is the master device, and is used for generating a log file list according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device when it is detected that the condition for reporting the log file to the third device is met; sending the log file list to the third device;

[0039] The third device is configured to retrieve a file name from the list of log files, generate a file information acquisition request based on the retrieved file name, and send the file information acquisition request to the first device;

[0040] The first device is further configured to, in response to the file information acquisition request, determine the file name specified in the request; if the specified file name carries the device identifier of the target second device, perform a master-slave switch with the target second device, so that the target second device switches to be the master device to communicate with the third device, in order to send the file information of the second compressed log file in the target second device to the third device, for the third device to perform the sub-packet collection operation of the second compressed log file on the target second device according to the received file information; wherein, the target second device is one of the at least one second device.

[0041] In the seventh embodiment of the present application, a log reporting system is further provided, and the system includes:

[0042] A third device with a log file collection function;

[0043] A first device communicatively connected to the third device, and is configured to receive a log data acquisition request sent by the third device for the first compressed log file in the first device; wherein, the log data acquisition request carries the start offset, data size, and frame log bitmap of the target packet log data requested; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or indicates that all frame logs in the target packet log data need to be uploaded; obtain the target packet log data from the multi-packet log data included in the first compressed log file according to the start offset and the data size; if the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted, determine the frame numbers of the frame logs to be retransmitted according to the frame log bitmap; selectively retransmit multiple frame logs in the target packet log data to the third device according to the frame numbers and the negotiated frame length; if the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded, transmit multiple frame logs in the target packet log data to the third device frame by frame.

[0044] In the eighth embodiment of the present application, an electronic device is further provided, and the electronic device is the first device, the second device, or the third device. The electronic device includes: a memory, a processor, and a communication component; the memory is used to store programs; the processor is coupled to the memory;

[0045] When the electronic device is the first device or the second device, the electronic device further includes: a service component containing a log service module; the service component communicates with a corresponding external device through the communication component; the log service module is used to manage the logs generated by applications on the electronic device, and the management includes at least one of the following: performing hash processing on the logs, writing the hashed logs into corresponding log files, and compressing all the log files in the electronic device together;

[0046] Wherein, when the electronic device is the first device, the processor controls the service component to execute the program stored in the memory, so that the electronic device implements the steps in the log reporting method provided in the first, fourth, or fifth embodiment of the present application; when the electronic device is the second device, the processor controls the service component to execute the program stored in the memory, so that the electronic device implements the steps in the log reporting method provided in the second embodiment of the present application.

[0047] When the electronic device is the third device, the electronic device further includes a log collection application; the log collection application communicates with a corresponding external device through the communication component; the processor controls the log collection application to execute the program stored in the memory, so that the electronic device implements the steps in the log reporting method provided in the third embodiment of the present application.

[0048] In the technical solutions provided by the embodiments of the present application, a first device communicates with at least one second device in a master-slave manner and also communicates with a third device having a log file collection function. When the first device determines that the third device requests the file information of the second compressed log file in the target second device (one of the at least one second device), it will perform a master-slave switching operation, so that the target second device switches to be the master device to communicate with the third device. After the target second device communicates with the third device, it will send the file information of the second compressed log file therein to the third device, and the third device performs an interaction for reporting the second compressed log file with the target second device according to the received file information. By introducing a master-slave switch before the log file of the slave device is reported, this solution enables the slave device to directly report the log file therein to the third device without reporting it to the third device via the original master device, which can effectively reduce the log reporting process of the slave device, thereby reducing the time required for the slave device to report logs, and the log reporting efficiency is high. In addition, the first device will first perform a hash process on the logs generated by the applications thereon and then write them into the corresponding log files. When detecting the condition for reporting the log files to the third device, it will also compress all the log files in the first device into a compressed log file (the first compressed log file), and when determining that the third device requests the file information of the first compressed log file in the first device, it will send the file information of the first compressed log file to the third device for the third device to perform an interaction for reporting the first compressed log file with the first device according to the received file information (sub-packet collection). By introducing the hash and compression processes of the logs, this solution can significantly reduce the size of the log data, which is convenient for subsequently reducing the time required for log reporting and improving the log reporting efficiency. Further, in the process of the third device performing an interaction for reporting the log file with the first device according to the received file information of the first compressed log file in the first device (sub-packet collection), in the log data acquisition request sent to the first device for the first compressed log file, the starting offset, data size, and frame log bitmap of the target packet log data requested will be carried, where the carried frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or indicates that all frame logs in the target packet log data need to be uploaded; correspondingly, after receiving the log data acquisition request, the first device will obtain the target packet log data from the multi-packet log data included in the first compressed log file according to the starting offset and data size carried in the request; if the frame log bitmap carried in the request indicates that some frame logs in the target packet log data need to be retransmitted, the first device will determine the frame numbers of the frame logs that need to be retransmitted according to the frame log bitmap, and according to the frame numbers and the negotiated frame length, selectively retransmit the multi-frame logs in the target packet log data to the third device; if the frame log bitmap carried in the request indicates uploading all frame logs in the target packet log data, the multi-frame logs in the target packet log data will be sent frame by frame to the third device.It can be seen that this solution also introduces a log selective retransmission mechanism based on a bitmap, which can achieve fast retransmission of lost frame logs. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation of the present application. In the drawings:

[0050] Figure 1a is a schematic diagram of the principle of log reporting of existing Bluetooth devices provided by an exemplary embodiment of the present application;

[0051] Figure 1b is a schematic diagram of the principle of log viewing through a Web client provided by an exemplary embodiment of the present application;

[0052] Figure 2 is a schematic diagram of the principle of log reporting of existing master-slave devices provided by an exemplary embodiment of the present application;

[0053] Figure 3 is a schematic diagram of the principle of frame-by-frame reporting of existing log files provided by an exemplary embodiment of the present application;

[0054] Figure 4a 、 Figure 4b and Figure 5 is a schematic diagram of the structure of the log reporting system provided by an embodiment of the present application;

[0055] Figure 6 is a schematic diagram of the process of the log reporting method provided by an exemplary embodiment of the present application;

[0056] Figure 7 is a schematic diagram of the principle of problem feedback provided by an exemplary embodiment of the present application;

[0057] Figure 8 is a schematic diagram of the principle of sub-packet reporting of log files provided by an exemplary embodiment of the present application;

[0058] Figures 9 to 12 is a schematic diagram of the process of the log reporting method provided by an embodiment of the present application;

[0059] FIG. Figure 13a and Figure 13b are schematic diagrams of the log reporting timing process provided by the present application;

[0060] Figures 14 to 18 is a schematic diagram of the structure of the log reporting device provided by an embodiment of the present application;

[0061] Figure 19 and Figure 20Schematic structural diagram of the electronic device provided by the embodiment of the present application. Detailed implementation manners

[0062] With the development and popularization of rich devices such as mobile phones and tablets, various other products that communicate with rich devices for collaborative use, such as thin devices like earphones, watches, and bracelets, have emerged in an endless stream. Taking a Bluetooth thin device (a thin device that communicates based on the Bluetooth protocol) as an example, during the use of a Bluetooth thin device, problems such as lag, noise, or interruption often inevitably occur. In order to analyze the fault problems of Bluetooth thin devices, provide users with a product service that can quickly respond to and solve fault problems, and at the same time, in order to facilitate providing data support for the iterative update of subsequent products and provide users with higher-quality products, the product needs to have the ability to report log files.

[0063] A log file is a record of a certain process that has been completed by a device system or an application thereon for future reference. Currently, for the log file reporting of the above-mentioned Bluetooth thin devices, a service component (WearSDK) that provides a log service is often developed. This service component provides external interfaces that can be integrated by products as needed. After a Bluetooth thin device integrates the above service component, it has the ability to report log files. Specifically, as shown in Figure 1a The log reporting process is as follows: After a Bluetooth thin device integrates WearSDK, the business services within WearSDK and the logs generated by the applications on the device will call the corresponding interfaces through WearSDK to save the logs to the corresponding log files in the device; when a fault problem occurs during the use of the Bluetooth thin device, the user can operate the Bluetooth rich device to trigger a problem feedback for the Bluetooth thin device; in response to the triggered problem feedback, the Bluetooth rich device will synchronously request the Bluetooth thin device to report the logs, and after the Bluetooth rich device is connected to the network, it will package the log files reported by the Bluetooth thin device and the log files of the Bluetooth rich device and report them together to the server on the network side through the network for storage in the database of the server; R & D personnel can enter log retrieval conditions, such as log ID (such as the ID corresponding to the Bluetooth rich device (or the log collection application installed thereon, such as the Smart Space application)), system version, log collection application version, approximate time of problem occurrence, etc., through the website page (log viewing page P) provided by the Web client, and then click the "Query" control. In response to this query operation, the Web client will feedback the device logs that meet the retrieval conditions found for the R & D personnel through the website page, such as the device logs shown on the Figure 1b log viewing page P shown; further, the R & D personnel can view and analyze the device logs by triggering the operation of "Copy and Open the Device Log Download Link" for the corresponding logs, so as to respond to and solve the problems feedback by the users.

[0064] The existing Bluetooth low energy device log file reporting process described above has the following problems in several aspects:

[0065] 1. In the scenario where the Bluetooth low energy device is a master-slave device (including the master device and the slave device, which communicate as master and slave, and the master device communicates with the full-featured device), it is necessary to obtain the log file of the slave device through the interaction between the master and slave devices. Further, the log file of the slave device is reported to the Bluetooth full-featured device through the master device. Specifically, as shown in Figure 2 the schematic diagram of the log file reporting process of the master-slave device, the log file reporting process of the master device includes four steps: 1-2-3-4, while the log file reporting process of the slave device, such as the slave device 1, includes seven steps: 1-2-3-3.1-3.2-3.3-3.4. Obviously, the log file reporting process of the slave device is significantly longer than that of the master device, which leads to problems such as longer reporting time and slower speed for the log file of the slave device.

[0066] 2. The Bluetooth low energy device does not perform any processing operations on the log file, but directly reports the original log file, resulting in a relatively large size of the finally reported log file. Consequently, the log file reporting is slow, time-consuming, and has low reporting efficiency.

[0067] 3. Packet loss rate problem. During the log file reporting process, due to the need to balance the efficiency of log reporting and consider the size and frequency of the underlying transmit buffer of the Bluetooth low energy device, there is often a packet loss problem in the log file reporting after compromise. In addition, as shown in Figure 3 the existing log file reporting process, the Bluetooth low energy device divides the log file into multiple frames of log data. The log collection application on the Bluetooth full-featured device makes only one request to the Bluetooth low energy device for the log file of the Bluetooth low energy device. In response to the request, the Bluetooth low energy device will report the multiple frames of log data in the log file to the log collection application on the Bluetooth full-featured device frame by frame. Since the entire reporting process does not respond to the acknowledgment of the log collection application (and the log collection application has no acknowledgment), the Bluetooth low energy device cannot know which frames are lost during the upload process, resulting in frame loss problems, which may lead to the loss of key log information and affect the analysis efficiency and accuracy of user feedback problems.

[0068] In view of the above problems, the basic design idea for implementing log reporting in this application is as follows: For the scenario of master-slave device log reporting, the role switching between the master and slave devices is introduced before the log files of the slave device are reported; in addition, before the thin device executes log reporting, the thin device is also introduced to perform hash processing on the generated logs, write the hashed logs into the corresponding log files, and compress all the log files in the device into a compressed log file for reporting; and, during the process of the log file reporting process, a selective retransmission mechanism based on bitmap is also introduced. Based on the bit information recorded in the bitmap, it can be known which frame log data is lost during transmission for a request, so that the lost log data frames can be quickly resent to the rich device (specifically, the log collection application on the rich device) in the next request.

[0069] Based on the above basic design idea, the embodiments of this application provide a log reporting method, system and electronic device.

[0070] Details about the rich device and the thin device will be introduced in the following text.

[0071] To make the objectives, technical solutions and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments of this application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this application without creative efforts shall fall within the scope of protection of this application.

[0072] In the embodiments of this application, in order to facilitate a clear description of the technical solutions of the embodiments of this application, terms such as "first" and "second" are used to distinguish the same items or similar items with basically the same functions and roles. For example, the first signal generation circuit and the second signal generation circuit are only used to distinguish different signal generation circuits, and do not limit their sequence. Those skilled in the art can understand that terms such as "first" and "second" do not limit the quantity and execution order, and terms such as "first" and "second" do not necessarily limit being different.

[0073] It should be noted that in this application, words such as "exemplary" or "for example" are used to give examples, illustrations or explanations. Any embodiment or design solution described as "exemplary" or "for example" in this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Specifically, the use of words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner. In addition, "at least one" in this application means one or more, and "a plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. Among them, A and B can be singular or plural, etc. The character " / " generally indicates that the associated objects before and after are in an "or" relationship. "At least one (item)" or its similar expression below refers to any combination of these items, including any combination of a single item or plural items. For example, at least one (item) of a, b, and c can represent: a, b, c, a, b, and c, a and b, a and c, b and c.

[0074] The following will detail the technical solutions provided by each embodiment of this application in conjunction with the accompanying drawings.

[0075] Each method embodiment provided by this application can be implemented on the corresponding hardware of the following log reporting system. Specifically,

[0076] In a specific implementation manner, refer to Figure 4a and Figure 4b , the log reporting system includes: a first device 10, at least one second device 20, and a third device 30. Among them, the first device 10 is master-slave communication connected to at least one second device 20 through a communication module, and in the master-slave communication connection, the first device 10 is the master device and the second device 20 is the slave device; in addition, the first device is also communication connected to the third device 30 through a communication module. The third device has a log file collection function. Specifically, when implemented, an application with a log collection function (abbreviated as a log collection application in the context, such as a smart space application) is installed on the third device, and the third device realizes log file collection through this log collection application.

[0077] The above-mentioned first device 10 is used to generate a log file list according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device when it detects that the condition for reporting the log file to the third device is met; and send the log file list to the third device 30;

[0078] The third device 30 is configured to retrieve a file name from the list of log files, generate a file information acquisition request based on the retrieved file name, and send the file information acquisition request to the first device 10;

[0079] The first device 10 is further configured to, in response to the file information acquisition request, determine the file name specified in the request; if the specified file name carries the device identifier of the target second device, perform a master-slave switch with the target second device, so that the target second device switches to be the master device to communicate with the third device, in order to send the file information of the second compressed log file in the target second device to the third device, for the third device to perform the sub-packet collection operation of the second compressed log file on the target second device according to the received file information; wherein, the target second device is one of the at least one second device 20.

[0080] The above-mentioned first device 10 and second device 20 are often thin devices. A thin device refers to a device with limited resources. The device with limited resources may refer to an electronic device with a storage space less than or equal to a first threshold, and / or a processing performance less than or equal to a second threshold, and / or a relatively single provided function, etc. Generally, an electronic device with less memory and less storage space can be called a thin device. Specifically, in implementation, the thin device (the first device, the second device) may include, but is not limited to, wireless Bluetooth headsets (referred to as Bluetooth headsets), smart wearable devices such as bracelets and watches, smart speakers (speakers), wireless Bluetooth microphones (microphones), wireless Bluetooth keyboards and mice, etc. In addition to integrating a communication component, the thin device (the first device, the second device) also integrates other components, such as a service component (WearSDK). WearSDK provides a log service. In other words, WearSDK contains a log service module. The log service module (referred to as the log service) can manage the logs generated by the device. The management includes, but is not limited to, hashing the logs, writing the hashed logs into the corresponding log files, and compressing the log files. Through the service component, the thin device can report the corresponding log files to the rich device (the third device). The specific implementation of log file reporting is described in detail in the method examples provided below.

[0081] The above-mentioned third device is a rich device. A rich device (or a fat device) refers to a device with rich resources. The device with rich resources may refer to an electronic device with a storage space greater than a first threshold, and / or a processing performance greater than a second threshold, and / or a diverse provided function, etc. Generally, an electronic device with sufficient memory and sufficient storage space can be called a rich device. Specifically, in implementation, the rich device (the third device) may include, but is not limited to, mobile phones, tablets, laptop computers, etc.

[0082] When implementing the corresponding communication connections among the above-mentioned first device 10, second device 20, and third device 30, the communication module used can be a wireless communication module, such as communication components for short-distance communication like a Bluetooth module, a Wifi module, a Zigbee (self-bee technology), etc. Figure 4b The situation where the communication module used is a Bluetooth module is shown in. Figure 4b In the shown situation, the above-mentioned first device 10 and second device 20 can be referred to as Bluetooth thin devices, and the third device 30 can be referred to as a Bluetooth rich device.

[0083] The above-mentioned Figure 4a and Figure 4b show a schematic structural diagram of a log reporting system including master and slave devices. Of course, the log reporting system may not include master and slave devices. Based on this:

[0084] In another specific implementable technical solution, as shown in Figure 5 , the log reporting system includes: a third device 30 and a first device 10; where.

[0085] The third device 30 has a function of collecting log files

[0086] The first device, which is communicatively connected to the third device, is used to receive a log data acquisition request sent by the third device for the first compressed log file in the first device; where the log data acquisition request carries the start offset, data size, and frame log bitmap of the target packet log data requested; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or indicates that all frame logs in the target packet log data need to be uploaded; according to the start offset, obtain the target packet log data from the multiple packet log data included in the first compressed log file; if the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted, determine the frame numbers of the frame logs that need to be retransmitted according to the frame log bitmap; according to the frame numbers and the negotiated frame length, selectively retransmit multiple frame logs in the target packet log data to the third device; if the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded, transmit multiple frame logs in the target packet log data frame by frame to the third device.

[0087] For the introduction of the communication connection method between the first device and the third device and the specific forms of the first device and the third device, reference can be made to the relevant content above, and details will not be elaborated here. Figure 5 Figure (b) shown on the left in shows an example of the communication connection method between the first device (Bluetooth thin device) and the third device (Bluetooth rich device) being Bluetooth communication.

[0088] Specific details of the corresponding functions of the first device, the second device, the third device, and other hardware in each of the above-mentioned log reporting systems will be described in detail in the following method embodiments.

[0089] Figure 6 The flowchart of the log reporting method provided by an embodiment of the present application is shown. The execution subject of all steps in the method of this embodiment can be the first device in the above system. More specifically, the steps in the method can be executed by the service component (WearSDK) in the first device. The first device is the master device and communicates with at least one second device in a master-slave manner. The first device also communicates with a third device having a log file collection function. For the description of the first device, the second device, the third device, and their mutual communication methods, reference can be made to the relevant content in other embodiments of the present application.

[0090] As shown in Figure 6 , the log reporting method provided by this embodiment includes the following steps:

[0091] 101. When it is detected that the condition for reporting the log file to the third device is met, generate a log file list according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device;

[0092] 102. Send the log file list to the third device;

[0093] 103. In response to the file information acquisition request sent by the third device according to the log file list, determine the file name specified in the request;

[0094] 104. If the specified file name carries the device identifier of the target second device, perform a master-slave switch with the target second device, so that the target second device switches to be the master device and communicates with the third device, in order to send the file information of the second compressed log file in the target second device to the third device, for the third device to perform a sub-packet collection operation on the second compressed log file of the target second device according to the received file information; where the target second device is one of the at least one second device.

[0095] In the above 101, the reporting timing of the log file can be a passive timing or an active timing. Among them, the passive timing means being triggered by the third device, and the active timing means being actively triggered by the first device. When the reporting timing of the log file is reached, it is determined that the condition for reporting the log file to the third device is met.

[0096] Based on this, "detecting that the condition for reporting the log file to the third device is met" in the above 101 can include:

[0097] ①Receive the log file list acquisition request sent by the third device, and determine the conditions for reporting the log file to the third device; and / or

[0098] ②When the log file meets the set requirements, determine the conditions for reporting the log file to the third device; where meeting the set requirements includes at least one of the following: reaching the reporting period, the number of log files reaching the set number, and the storage duration of the log file reaching the set duration.

[0099] In the above ①, the log file list acquisition request can be sent by the third device according to the problem feedback operation triggered by the user.

[0100] For example, when the first device and / or the second device has anomalies such as lags and noises during use, in response to this anomaly, the user can trigger an anomaly feedback by operating the log collection application installed on the third device and click to confirm. The log collection application will, in response to the user operation, send a log file list acquisition request to the first device that is communicatively connected to the third device through the third device. More specifically, see Figure 7 and in combination with Figure 5, taking the log collection application on the third device 30 as an example of the smart space application, a transmission channel (such as the UUID Bluetooth service channel of XXXX) is created between the smart space application and the service component (WearSDK) on the first device through the communication module on the third device and the communication module on the first device for log reporting interaction; the user can enter the "Help and Customer Service" page by operating the "Help and Customer Service" function on the smart space application page. There is an "Issue Feedback" entry on this page. Clicking on this "Issue Feedback" entry will enter the issue feedback page, and corresponding issue feedback information can be entered on this issue feedback page, such as checking the device for which the problem needs to be reported (such as checking device 1 (the first device)), filling in the device problem description (the problem that occurred with the device), the probability of occurrence, the time, etc. After that, clicking the "Submit" control will trigger the smart space application to collect the corresponding device-side log file process. Specifically, when implementing, in response to the above submission operation, the smart space application will first generate a log file list acquisition request according to the issue feedback information entered by the user; then, based on the corresponding internal private related protocol (such as the MBB protocol), after encapsulating the log file list acquisition request information with the protocol, it will send the log file list acquisition request information to the first device selected by the user through the communication module of the third device via the transmission channel with the first device; after receiving the log file list request information (as a binary byte stream), the first device will pass the log file list acquisition request information to the WearSDK on the first device through the communication module on it and the external interface provided by the WearSDK on the first device; the WearSDK on the first device will parse the received log file list request information with the internal private related protocol such as the MBB protocol, identify the specific service type (log service) and request type (log file list request), so when it is determined that the request type is a log file list request, it is determined that the condition for reporting the log file to the third device is met.

[0101] In the above ②, the reporting period, the set quantity, the set duration, etc. can be flexibly set according to the actual situation and are not limited here. The first device can automatically trigger the log file reporting according to the set requirements without waiting for the third device to issue a log reporting instruction, such as waiting for the first device to issue the log file list acquisition request described in the above ①.

[0102] In the embodiment of the present application, preferably, the method described in the above ① is used to determine whether the condition for reporting the log file to the third device is met.

[0103] After meeting the conditions for reporting log files to the third device, the first device and the second device will each perform a compression action on multiple log files in themselves to obtain corresponding compressed log files. The purpose of performing the compression action here is to reduce the volume of the log files (i.e., the size of the log files), so as to shorten the time required for reporting the log files and improve the reporting efficiency in the subsequent reporting process. Among them, the second device triggers the log file compression action according to the log file list acquisition request synchronized from the first device, and will return the file name of the second compressed log file obtained after compression to the first device for the first device to generate a log file list. Based on this, before triggering the execution of the above 101 "generate a log file list according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device", the method provided in this embodiment may further include the following steps:

[0104] 100a. Send notifications to the at least one second device respectively to notify the preparation for reporting log files;

[0105] 100b. Compress the multiple log files in the first device together to obtain the first compressed log file; the file name of the first compressed log file carries the device identifier of the first device;

[0106] 100c. Receive the file names of the second compressed log files sent by the at least one second device respectively; wherein, the second compressed log file is obtained by the second device compressing multiple log files in the second device together in response to the notification; the file name of the second compressed log file carries the device identifier of the second device.

[0107] In the above 100a, after the first device determines that the WearSDK on it receives a log file list acquisition request, it can synchronize the log file list acquisition request information to the second device through the master-slave transmission channel (Bluetooth service channel) created when establishing a communication connection with the second device, so as to notify the second device to prepare for reporting log files. That is, the notification sent to the second device may refer to the log file list acquisition request information.

[0108] In the above 100b, after the first device receives the log file list acquisition request, in addition to performing the synchronization operation described in the above 100a, the WearSDK on it (more specifically, the log service in the WearSDK) will also start to execute the log file compression action to compress multiple log files in the first device (which can be called the main ear log files) into a compressed log file (the first compressed log file). Specifically, in implementation, as shown in Figure 5 , the compression module can be called to compress multiple log files in the first device together to obtain the first compressed log file (such asFigure 5 The medium log file.zip). Among them, during the compression process, according to the agreed file name generation rules, the corresponding file name will be generated for the first compressed log file. Specifically, the file name of the first compressed log file contains the device identifier of the first device. For example, taking the compression method using zip (an archive file format that supports lossless data compression) as an example, the file name format of the first compressed log file can be: XXX_master.zip, and the master field in the file name represents the device identifier of the first device.

[0109] Among them, the logs in the log file of the above-mentioned first device can be the logs generated by the first device for the applications on it after hashing and written into the corresponding log file to further reduce the volume of the log file. Based on this, the method provided in this embodiment may further include the following steps:

[0110] S11. Obtain the logs generated by the applications on the first device;

[0111] S12. Perform hashing on the logs generated by the applications to obtain the hashed logs;

[0112] S13. Write the hashed logs into the log file corresponding to the applications.

[0113] Specifically, when implemented, the applications on the first device include but are not limited to: business applications in WearSDK, communication modules (such as Bluetooth modules), power modules, etc. Among them, the services provided by the SDK include log services and other types of business services (such as data sending and receiving services (corresponding applications are data sending and receiving modules), etc.). The logs generated by the applications on the first device may refer to the logs generated by the corresponding applications during the non-log reporting service interaction process between the first device and the third device. The non-log reporting service interaction includes but is not limited to: device registration, power reporting, information query interaction, etc.

[0114] For example, when the third device is paired and connected with the first device through the Bluetooth module to establish communication, the third device will first scan, detect and identify the first device, and send a device registration request to the detected first device to perform device registration interaction with the first device. During this process, the third device will generate corresponding device registration interaction logs. Correspondingly, the registration module corresponding to WearSDK in the first device will also generate corresponding device registration response logs.

[0115] For another example, when the user operates the third device to query the connection status, power, noise control information, sound effect, device information, quick operation, firmware update, usage guide, etc. of the first device, the third device will generate corresponding information query logs; correspondingly, the device management module corresponding to WearSDK in the first device will generate corresponding query response logs.

[0116] For another example, after establishing a communication connection with the first device, the third device will synchronize some information, such as time information, to the first device. Further, the first device will synchronize the received information, such as time information, to the second device for storage through the master-slave transmission channel between the first device and the second device. During this information synchronization process, the respective data transceiver modules related to WearSDK in the first device and the second device will generate corresponding logs.

[0117] After the first device obtains the logs generated by the applications thereon, it can call the log API with a hash function therein to perform hash processing on the obtained logs (raw logs) to obtain the hashed logs, and write the hashed logs into the log file corresponding to the application for storage. Among them, hash processing means: input data of any length (in this example, the obtained log information) is processed through a hash algorithm to obtain an output data of a fixed length (referred to as a hash value (Hash value, message digest)).

[0118] In the above 100c, in response to the notification, the WearSDK on the second device (more specifically, the log service in the WearSDK) will start to execute the log file compression action, and compress multiple log files (which can be called slave ear log files) in the second device into a compressed log file, that is, the second compressed log file. The file name of the second compressed log file carries the device identifier corresponding to the second device. For example, the file name format of the second compressed log file can be: XXX_slave.zip, and the slave field in the file name represents the device identifier corresponding to the second device.

[0119] For the specific implementation description of the second device executing the log file compression action, reference can be made to the relevant content of the first device executing the log file compression action described in the above 100b. And for the detailed description of the logs in the log files of the second device, reference can be made to the relevant content of the log files in the first device described in combination with the above steps S11 - S13.

[0120] Further, after the first device compresses multiple log files therein together to obtain the first compressed log file, it can also perform packet splitting on the first compressed log file to facilitate subsequent reporting the first compressed log file in packets to the third device according to the request of the third device. Thus, the method provided in this embodiment may further include the following steps:

[0121] 100b_1. Divide the first compressed log file into multiple packets of log data, so as to subsequently report the first compressed log file in packets to the third device; wherein, one packet of log data contains multiple frames of logs.

[0122] In specific implementation, the WearSDK in the first device divides the first compressed log file into multiple packets of log data according to a preset packet division strategy. The preset packet division strategy includes, but is not limited to, the maximum number of frames that each packet of log data can contain and the frame length of the frame log. The above maximum number of frames can be 8 frames or 16 frames, etc. Specifically, it can be determined by the WearSDK manufacturer according to the size of the buffer sent by the communication module (such as a Bluetooth module). For example, if the sent buffer is relatively large, the maximum number of frames can be selected as 16 frames; conversely, if the sent buffer is relatively small, the maximum number of frames can be selected as 8 frames. In this embodiment, preferably, the maximum number of frames is 8 frames.

[0123] When dividing the first compressed log file into packets, the starting offset of the first packet of log data (the first packet of log data) is 0, and the corresponding ending offset is equal to its starting offset plus the product value of the maximum number of frames and the frame length; the starting offset of the second packet of log data is equal to the ending offset of the first packet of log data, and the corresponding ending offset is equal to the starting offset of the second packet of log data plus the product value of the maximum number of frames and the frame length; and so on, until the last packet of log data is divided. Among them, when the total file length (total file size) of the first compressed log file cannot be divided evenly by the product value of the maximum number of frames and the frame length, the number of frame logs contained in the last packet of log data is less than the maximum number of frames.

[0124] Similarly, the second device can also divide the second compressed log file in it into multiple packets of log data. For the specific implementation description of the second device dividing the second compressed log file in it into multiple packets of log data, reference can be made to the specific implementation process of the first device dividing the second compressed log file in it into multiple packets of log data described above.

[0125] Figure 8 Shows an example of packet division of a compressed log file (such as the first compressed log file or the second compressed log file).

[0126] After the WearSDK on the first device obtains the file name of the first compressed log file in the first device and the file names of the second compressed log files sent by each second device, it will separate the file names with a delimiter (such as a semicolon ";" or a comma ",", etc.) to generate a log file list.

[0127] For example, in combination with Figure 4a, assuming the file name of the first compressed log file in the first device is XXX_master.zip, the file name of the second compressed log file in the obtained second device 21 is XXX_slave21.zip, and the file name of the second compressed log file in the second device 22 is XXX_slave22.zip, then the generated log file list format can be: XXX_master.zip; XXX_slave21.zip; XXX_slave21.zip.

[0128] In the above 102, the WearSDK on the first device can send the generated log file list to the third device through the transmission channel with the third device.

[0129] In the above 103, the file information acquisition request is generated by the third device according to the received log file list. Specifically, after receiving the log file list, the third device can read the file names included in the log file list, take out one file name from them to generate a file information acquisition request, and then send the file information acquisition request to the first device, so that the first device can trigger corresponding operations according to the file name specified in the request.

[0130] In specific implementation, the third device can take out the file names in the log file list according to the built-in file name extraction strategy to generate a file information acquisition request. The file name extraction strategy can be a sequential extraction strategy according to the sorting order or a random extraction strategy, which is not limited here.

[0131] For example, taking the sequential extraction strategy according to the sorting order as an example, the third device can sequentially select the file names in the log file list according to the sorting order of the file names. For example, continuing the above example, the sorting order of the file names in the log file list is: XXX_master.zip; XXX_slave21.zip; XXX_slave21.zip. Then, the third device can first take out the file name XXX_master.zip to generate a file information acquisition request to request the file information of the first compressed log file, and after collecting the first compressed log file of the first device according to the received file information of the first compressed log file, then take out the next file name XXX_slave21.zip to generate another file information acquisition request, and so on.

[0132] Of course, the third device can also adopt a random extraction strategy and randomly take out a file name from the log file list to generate a file information acquisition request. In this embodiment, preferably, the file name extraction strategy is a sequential extraction strategy according to the sorting order.

[0133] After the first device receives a file information acquisition request, it will hand it over to the WearSDK on it to parse the file information acquisition request, and determine whether it is necessary to perform a master-slave device role switch (hereinafter referred to as master-slave switch) according to the file name specified in the parsed request. Specifically, if the device identifier of a certain second device (target second device) is included in the file name specified in the request, it is determined that a master-slave switch is required; conversely, if the device identifier of the first device is included in the file name specified in the request, it is determined that no master-slave switch is required. When it is determined that a master-slave switch is required, the first device will trigger the execution of the step of "performing a master-slave switch with the target second device" in the above 104, so that the target second device communicates with the third device.

[0134] Specifically, in an implementable solution, the "performing a master-slave switch with the target second device" in the above 104 may specifically include:

[0135] 1041. Send the communication connection information between the first device and the third device to the target second device, so that the target second device establishes a communication connection with the third device according to the communication connection information, and after establishing a communication connection with the third device, prohibit the target second device from spontaneously performing a master-slave switch;

[0136] 1042. Disconnect the communication connection with the third device.

[0137] In specific implementation, the WearSDK on the first device can obtain the communication connection information between the first device and the third device through the log service therein, and the first device sends the communication connection information to the target second device through the corresponding master-slave transmission channel. The target second device will initiate a communication connection request to the third device according to the received communication connection information between the first device and the third device to establish a communication connection with the third device. After the third device establishes a communication connection with the target second device, it will disconnect the communication connection with the first device.

[0138] In addition, after the target second device establishes a communication connection with the third device, it will also perform the following actions:

[0139] 1) Prohibit spontaneous master-slave switching between devices. The purpose is to prevent the spontaneous master-slave switching logic from being triggered due to the occurrence of certain events (such as low device power) during the subsequent transmission interaction of the second compressed log file with the third device, which affects the log file transmission.

[0140] 2) Report the device role status (as the master device role) of the current target second device to the WearSDK on it.

[0141] The Wear SDK on the target second device determines that the current device role status of the target second device is the master device role. After learning that the current status reported according to the saved current log file (the status is that the file information is to be reported) indicates that it is currently in the file information reporting process, a query request will be sent to the log service therein to query the file information of the second compressed log file in the target second device. In response to the query request, the log service will feedback the queried file information of the second compressed log file to the Wear SDK on the target second device. Further, the Wear SDK on the target second device will send the received file information of the second compressed log file to the third device (specifically, it is sent to the log collection application on the third device). Among them, the file information of the second compressed log file includes but is not limited to: the total file size (total file length), and the verification information, which is the verification value calculated by the target second device using corresponding data verification algorithms (such as SHA256 (a secure hash algorithm), CRC (cyclic redundancy check code), MD5 (Message-Digest Algorithm 5, a cryptographic hash function), etc.) for the second compressed log file. The calculated verification value can be but is not limited to a 32-bit or 16-bit (2-byte) binary value. After receiving the file information of the second compressed log file, the third device will perform a sub-packet collection operation on the target second device for the second compressed log file according to the total file size therein, and after the collection is completed, it can use the verification information therein to perform an integrity verification on the collected second compressed log file, so as to determine whether there is data tampering and / or frame loss, etc. in the collected second compressed log file according to the verification result.

[0142] For example, after the third device completes the sub-packet collection operation for the second compressed log file, it can merge all the packet log data collected, thereby obtaining the collected second compressed log file. Then, using the pre-set data verification algorithm therein, calculate the collected second compressed log file to obtain a calculated value. Compare this calculated value with the received verification value to determine the integrity and validity of the collected second compressed log file. For example, if the calculated value is the same as the received verification value, it can indicate that the collected second compressed log file is complete and valid; conversely, if the calculated value is different from the received verification value, it can indicate that the collected second compressed log file is incomplete and there may be problems such as data tampering and frame loss. When the collected second compressed log file is incomplete, the next operation to be performed can be determined according to the degree of incompleteness. For example, if the degree of incompleteness is greater than the set threshold, it means that the possible amount of data tampering and / or frame loss is relatively large, which may lead to the loss of key log information and make the collected second compressed log file become an invalid log file. In this case, the second compressed log file can be re-packaged and collected; if the degree of incompleteness is less than or equal to the set threshold, it means that the possible amount of data tampering and / or frame loss is relatively small, and the possibility of losing key log information is extremely small. The collected second compressed log file can be regarded as a valid log file and no re-collection is required. Among them, the degree of incompleteness of the collected second compressed log file can be determined, but not limited to, based on the difference between the calculated value and the received verification value.

[0143] It should be noted that: the data verification algorithm used by the third device matches the data verification algorithm used by the above-mentioned target second device. For example, if the target second device uses the CRC verification algorithm, the third device also uses the CRC verification algorithm.

[0144] The reported status of the current log file saved in the above-mentioned target second device is informed by the first device to the target second device. Thus, when the device identifier of the target second device is included in the specified file name, the method provided in this embodiment may further include the following steps:

[0145] S21. Send a reporting status notification to the target second device to inform the target second device that the reported status of the current log file is the file information waiting to be reported status of the second compressed log file.

[0146] For the specific implementation description of the third device performing the sub-packet collection operation of the second compressed log file on the target second device, reference can be made to the relevant content of the third device performing the sub-packet collection operation of the first compressed log file on the first device described below, and no specific elaboration will be made here.

[0147] After the third device completes the collection of the second compressed log file in the target second device, it will send the log file collection result to the target second device to notify the target second device that the log file transfer is completed. After the target second device determines that the log file transfer is completed based on the received notification, it will lift the prohibition on the target second device from performing a spontaneous master-slave switch.

[0148] In the technical solution provided in this embodiment, when the first device (acting as the master device) detects that the condition for reporting the log file to the third device is met, it will generate a log file list based on the file name of the first compressed log file in the first device and the file names of the second compressed log files in at least one second device (acting as the slave device), and send the list to the third device; further, in response to the file information acquisition request sent by the third device based on the log file list, it will determine the file name specified in the request; if the specified file name carries the device identifier of the target second device, it will perform a master-slave switch with the target second device (which is one of the at least one second device), so that the target second device switches to the master device to communicate with the third device, and send the file information of the second compressed log file in the target second device to the third device, for the subsequent third device to perform the sub-packet collection operation of the second compressed log file in the target second device according to the received file information. In the scenario of master-slave device log reporting, by introducing a master-slave device role switch before the slave device reports the log, enabling the slave device to switch to the master device, this solution allows the slave device to directly report the log file in it to the third device without having to report it to the third device via the original master device, which can effectively shorten the log reporting process of the slave device, thereby reducing the time required for the slave device to report the log, and the log reporting efficiency is high.

[0149] Further, if the first device determines that the specified file name in the received file information acquisition request carries the device identifier of the first device, the first device does not need to perform a master-slave switch and will directly send the file information of the first compressed log file in it to the third device. That is, the method provided in this embodiment further includes the following steps:

[0150] 105. If the specified file name carries the device identifier of the first device, send the file information of the first compressed log file to the third device, for the third device to perform the sub-packet collection operation of the first compressed log file in the first device according to the file information of the first compressed log file and the log file transfer parameters negotiated with the first device.

[0151] The above file information of the first compressed log file includes the total file size and verification information, and the verification information is used for the third device to verify the collected first compressed log file. For the specific implementation description of obtaining the file information of the first compressed log file, reference can be made to the relevant content of the target second device obtaining the file information of the second compressed log file described above.

[0152] The above log file transfer parameters include at least one of the following: maximum transfer length, frame length of frame logs, transfer interval duration, and retransmission support status; wherein, the maximum transfer length is equal to the frame length multiplied by the maximum number of frame logs that can be connected and transferred for one log data acquisition request. The maximum number of frames can be 8 frames, 16 frames, etc. For a detailed description of the maximum number of frames, reference can be made to the relevant content in other embodiments. The retransmission support status refers to whether bitmap-based log retransmission is supported. Specifically, it refers to whether the bitmap-based log selective retransmission function is supported. In addition, the log file transfer parameters may also include other parameters, such as the transfer protocol version, etc.

[0153] After receiving the file information of the first compressed log file, the third device will start to execute a log data acquisition request to the first device according to the total file size of the first compressed log file in the file information and the log file transfer parameters, so as to perform sub-packet collection on the first compressed log file in the first device. Among them, one log data acquisition request is used to request one packet of log data included in the multiple packets of log data of the first compressed log file, and the log data acquisition request to the first device is stopped until the collection of the first compressed log file is completed. And after the collection is completed, the check information in the file information can also be used to check whether the collected first compressed log file is complete and valid. For a specific implementation description of the check, reference can be made to the relevant content of checking the collected second compressed log file described above, and details will not be elaborated here.

[0154] Specifically, when the retransmission support status included in the log file transfer parameters supports bitmap-based log retransmission, during the sub-packet collection operation of the first compressed log file on the first device by the third device, each log data acquisition request sent to the first device will carry a frame log bitmap, and each bit in the frame log bitmap (Bit, simply referred to as "bit") is used to store the received status of the corresponding frame log.

[0155] Taking the maximum number of frames as 8 frames as an example, the frame log bitmap can be as shown in Table 1 below:

[0156] Table 1 Frame Log Bitmap

[0157] Bit 0 1 2 3 4 5 6 7 Frame log received status value 0 0 0 0 0 0 0 0

[0158] How to carry the frame log bitmap in the log data acquisition request will be described in detail below.

[0159] Based on the above content, when the retransmission support status supports bitmap-based log retransmission, the method provided in this embodiment further includes the following steps:

[0160] 106. Receive a log data acquisition request sent by the third device for the first compressed log file; wherein, the log data acquisition request carries the starting offset, data size, and frame log bitmap of the target packet log data requested; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or indicates that all frame logs in the target packet log data need to be uploaded; the target packet log data is one packet of log data included in the multiple packet log data included in the first compressed log file.

[0161] 107. Obtain the target packet log data from the multiple packet log data included in the first compressed log file according to the starting offset and the data size.

[0162] 108. If the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted, determine the frame numbers of the frame logs that need to be retransmitted according to the frame log bitmap; selectively retransmit multiple frame logs in the target packet log data to the third device according to the frame numbers and the negotiated frame length.

[0163] 109. If the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded, transmit multiple frame logs in the target packet log data frame by frame to the third device according to the frame length.

[0164] For ease of understanding the above steps 106 to 109, the following is a detailed description. In the following description process, it is introduced by taking the example that the first device can continuously send 8 frames of logs for one log data acquisition request.

[0165] The third device sends a first log data acquisition request (first log data acquisition request) to the first device according to the total file size of the first compressed log file (assuming it is greater than the maximum transmission length) and the negotiated log file transmission parameters. This first log data acquisition request is used to request the first packet of log data ranked first in the multiple packet log data in the first compressed log file. Accordingly, the starting offset carried by the first log data acquisition request for the requested first packet of log data is 0, the data size is the negotiated maximum transmission length, and all the values corresponding to the bits in the frame log bitmap are 0 (as shown in Table 1, indicating that this request is for requesting a new packet of log data and all frame logs in the requested packet of log data (the first packet of log data) need to be uploaded). After receiving the above first log data acquisition request, the first device, after parsing, will determine that the requested is the first packet of log data in the first compressed log file (such as Figure 8Package 1 shown in; and determine that all frame logs in the first packet log data need to be uploaded according to the frame log bitmap carried in the request; according to the determined result above, the first device will send multiple frame logs in the first packet log data frame by frame to the third device according to the negotiated frame length, where the sent frame log will carry a psn field indicating which frame the currently sent frame log is, that is, the psn field represents the frame number of the currently sent frame log, so that the third device can mark the received status of the received frame log in the corresponding frame log bitmap according to the psn field.

[0166] For example: The starting offset corresponding to the first frame log in the first packet log data is the starting offset 0 of the first packet log data, and the ending offset is the starting offset of the first packet log data + frame length. According to the starting offset and ending offset of the first frame log, the first device can send the first frame log in the first packet log data to the third device, where the field value of the psn field carried by the first frame log can be 0, indicating that the currently sent frame log is the 0th frame log (i.e., the first frame log) in the first packet log data. The third device will set the value of bit 0 corresponding to frame number 0 in the frame log bitmap shown in Table 1 to the received value (such as 1) according to the frame number 0 (i.e., the psn field is 0) carried by the received first frame log. And so on, the first device can send other frame logs in the first packet log data to the third device, and correspondingly, the third device can also set the values of the corresponding bits in the frame log bitmap shown in Table 1 for the received other frame logs.

[0167] When the 7th frame log (the frame log with frame number 7) is received or the waiting duration times out (exceeds the negotiated transmission interval duration), the next log data acquisition request process will be triggered.

[0168] Assume that when reaching the timing to trigger the next log data acquisition request process, the third device does not receive the 4th frame log and the 6th frame log in the first packet log data, that is, the frame logs with frame numbers 4 and 6 are lost during transmission. Then the final frame log bitmap for the first packet log data is as shown in Table 2 below:

[0169] Table 2

[0170] Bit 0 1 2 3 4 5 6 7 Frame log received status value 1 1 1 1 0 1 0 1

[0171] Based on the frame log bitmap shown in Table 2, the third device will continue to generate a second log data acquisition request according to the start offset, data size of the first packet log data, and the frame log bitmap shown in Table 2, and send it to the first device. That is, the start offset carried by the second log data acquisition request = the start offset of the first packet log data carried by the first log data acquisition request, the data size carried is equal to the data size carried by the first log data acquisition request, and the frame log bitmap carried is the frame log bitmap finally corresponding to the first packet log data obtained through the first log data acquisition request (as shown in Table 2). The frame log bitmap carried this time indicates that some frame logs in the first packet log data need to be retransmitted.

[0172] After receiving this second log data acquisition request, the first device can know, based on the frame log bitmap carried by the request, that the 4th frame log and the 6th frame log in the first packet log data need to be retransmitted (i.e., the frame logs with frame numbers 4 and 6). Based on this, the first device can determine the start offset position of the 4th frame log = frame length * 4 and the end offset position = frame length * (4 + 1) according to frame number 4 and the frame length. Thus, according to the start offset and end offset positions of the 4th frame log, the 4th frame log is retransmitted to the third device. Similarly, the 6th frame log in the first packet log data can also be retransmitted to the third device.

[0173] Again, assume that when the timing to trigger the next log data acquisition request process is reached, the third device receives all the frame logs in the first packet log data, that is, there is no frame loss during the transmission of the first packet log data. Then, the frame log bitmap finally obtained for the first packet log data is as shown in Table 3 below:

[0174] Table 3

[0175] Bit 0 1 2 3 4 5 6 7 Frame log received status value 1 1 1 1 1 1 1 1

[0176] Based on the frame log bitmap shown in Table 3, the third device will send a second log data acquisition request to the first device for the second packet log data in the first compressed log file. Among them, the starting offset of the second packet log data carried in the second log data acquisition request = the starting offset of the first packet log data carried in the first log data acquisition request + the data size of the first packet log data, that is, the starting offset of the second packet log data carried is equal to the ending offset of the first packet log data, and all the values of the bits in the frame log bitmap of the second packet log data carried are 0 (as shown in Table 1, indicating a new packet log data acquisition request, and all frame logs in the second packet log data need to be uploaded). The data size of the second packet log data carried in the second log data acquisition request is related to the following two factors: whether the second packet log data is the last packet log data in the first compressed log file, and whether the total file size of the first compressed log file can be divided evenly by the negotiated maximum transmission length allowed for the third device to apply for. If the second packet log data is not the last packet log data in the first compressed log file, the data size carried in the second log data acquisition request is the maximum transmission length. If the first packet log data is the last packet log data in the second compressed log file and in the scenario where the total file size of the first compressed log file cannot be divided evenly by the negotiated maximum transmission length, the data size carried in the second log data acquisition request = the total file size of the first compressed log file minus the reported log data size (such as the data size of the first packet log data).

[0177] After receiving this second log data acquisition request, based on the frame log bitmap carried in the request, the first device can know that all frame logs in the second packet log data need to be uploaded. Based on this, the first device can send the multiple frame logs in the second packet log data frame by frame to the third device according to the frame length until the sending is completed. Correspondingly, for the received frame logs, the third device will mark the corresponding bits in the frame log bitmap corresponding to the second packet log data as received status.

[0178] And so on until the reporting of the first compressed log file is completed.

[0179] As can be seen from the above content, in the log file reporting process of this solution, a selective retransmission mechanism based on bitmap is introduced, so that based on the bit information recorded in the bitmap (frame log bitmap), it can be known whether there are lost frames and which specific frame logs are lost in the transmitted log data for a log data acquisition request, so that the lost frame logs can be resent quickly when responding to the next log data acquisition request.

[0180] Further, to avoid making circular requests for the same packet of log data multiple times, this embodiment also adds an interception of circular requests for the same packet of log data, and sets a non-processing strategy when the number of requests for the same packet of log data exceeds a certain number. Thus, before performing the above step 107, the method provided in this embodiment may further include the following steps:

[0181] S31. Determine the number of times of receiving the log data acquisition request carrying the starting offset;

[0182] S32. When the number of times is less than or equal to the preset number of times, trigger the execution of the above steps 107 to 109;

[0183] S33. When the number of times is greater than the preset number of times, do not respond to the log data acquisition request, but the log data acquisition request can be recorded.

[0184] The above preset number of times can be flexibly set according to the actual situation and is not limited here. For example, the preset number of times can be 3 times, 5 times, etc., but it should not be too large. Preferably, the preset number of times is 3 times.

[0185] Figure 9 The flowchart of the log reporting method provided in another embodiment of the present application is shown. The execution subject of all steps in the method of this embodiment can be the target second device. More specifically, the steps in the method can be executed by the service component (WearSDK) in the target second device. The target second device is one of at least one second device in the above system. At least one second device is a slave device for master-slave communication with the first device, and the first device also communicates with a third device having a log file collection function. For the description of the first device, the second device, the third device and their mutual communication methods, reference can be made to the relevant content in other embodiments. Such as referring to Figure 9 , the log reporting method provided in this embodiment includes the following steps:

[0186] 201. Receive the reporting status notification sent by the first device and the communication connection information between the first device and the third device; wherein, the reporting status notification is used to inform that the current log file reporting status is the file information to be reported status;

[0187] 202. Save the current log file reporting status;

[0188] 203. Establish a communication connection with the third device according to the communication connection information;

[0189] 204. After establishing a communication connection with the third device, report the status according to the saved current log file, and send the file information of the second compressed log file in the target second device to the third device, so that the third device can perform the sub-packet collection operation of the second compressed log file on the target second device according to the received file information;

[0190] Among them, the communication connection information is sent by the first device when performing master-slave switching with the target second device when it is determined that the file name specified in the received file information acquisition request contains the device identifier of the target second device; the file information acquisition request is sent by the third device to the first device according to the received log file list; the log file list is generated by the first device according to the file name of the first compressed log file in the first device and the file names of the second compressed log files in the at least one second device and sent to the third device; after the target second device establishes a communication connection with the third device, the device role status of the target second device is switched from a slave device to a master device, and the third device disconnects the communication connection with the first device.

[0191] Further, the method provided in this embodiment further includes the following steps:

[0192] 205. After establishing a communication connection with the third device, prohibit the target second device from spontaneously performing master-slave switching.

[0193] Further, the method provided in this embodiment may further include the following steps:

[0194] 206. Receive a log data acquisition request sent by the third device for the second compressed log file; wherein, the log data acquisition request carries the start offset, data size, and frame log bitmap of the requested target packet log data; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or all frame logs in the target packet log data need to be uploaded; the target packet log data is one packet of log data included in the second compressed log file;

[0195] 207. Obtain the target packet log data from the multi-packet log data included in the second compressed log file according to the start offset and the data size;

[0196] 208. If the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted, determine the frame numbers of the frame logs that need to be retransmitted according to the frame log bitmap; and selectively retransmit multiple frame logs in the target packet log data to the third device according to the frame numbers and the negotiated frame length.

[0197] 209. If the frame log bit table indicates that all frame logs in the target packet log data need to be uploaded, the multiple frame logs in the target packet log data are sent frame by frame to the third device.

[0198] Specifically, the third device sends a log data acquisition request to the target second device for the second compressed log file of the target second device based on the file information of the second compressed log file in the received target second device (more specifically, the total file size included in the file information) and the negotiated log file transfer parameters. One log data acquisition request is used to request one packet of log data. The log file transfer parameters can be obtained through negotiation between the third device and the first device. When it is determined that master-slave switching is required, the first device can synchronize the negotiated log file transfer parameters to the target second device. Of course, considering that the Bluetooth modules in the target second device and the first device may have differences in supported transmission performance, such as differences in supported transmission performance due to different protocol versions of the Bluetooth modules, in some instances, after establishing a communication connection with the target second device, the third device can also renegotiate the log file transfer parameters with the target second device. For the specific implementation description of the third device renegotiating the log file transfer parameters with the target second device, reference can be made to the relevant content described in other embodiments of this application regarding the negotiation of log file transfer parameters between the third device and the first device. Preferably, in the entire log reporting process of this embodiment, the third device only negotiates the log file transfer parameters with the first device once.

[0199] For the detailed description of the above steps 206-209, reference can be made to the relevant content described in other embodiments of this application regarding the reporting of the first compressed log file of the first device to the third device, such as the content related to steps 106-109 in other embodiments.

[0200] Furthermore, the method provided in this embodiment further includes the following steps:

[0201] 210. After receiving the notification that the collection of the second compressed log file sent by the third device is completed, lift the prohibition on the target second device from spontaneously performing master-slave switching.

[0202] Furthermore, the method provided in this embodiment further includes the following steps:

[0203] 200a1. When receiving the preparation log file reporting notification sent by the first device, compress multiple log files in the target second device together to obtain the second compressed log file; wherein, the file name of the second compressed log file carries the device identifier of the target second device;

[0204] 200a2. Send the file name of the second compressed log file to the first device.

[0205] Further, the method provided in this embodiment further includes the following steps:

[0206] 200a0_1. Obtain the logs generated by the application on the target second device;

[0207] 200a0_2. Perform hash processing on the logs to obtain the logs after hash processing;

[0208] 200a0_3. Write the logs after hash processing into the log file corresponding to the application.

[0209] For the specific implementation descriptions of the steps in the method provided in this embodiment above, reference may be made to the relevant content in other embodiments of this application, and specific details will not be elaborated here. In addition, the method provided in this embodiment may further include other steps in addition to the steps given above. For the other steps that may be included and their specific implementation descriptions, reference may also be made to the relevant content in other embodiments of this application.

[0210] Figure 10 The flowchart of the log reporting method provided in another embodiment of this application is shown. In the method of this embodiment, the execution subject of all steps is the third device in the above system. More specifically, it may be an application with a log collection function installed on the third device (abbreviated as the log collection application, such as the smart space application). The third device is communicatively connected to the first device, and the first device communicates with at least one second device in a master-slave manner, and the first device is the master device and the second device is the slave device in the master-slave communication. As shown in Figure 10 , the log reporting method provided in the embodiment of this application includes the following steps:

[0211] 301. Display an interactive interface;

[0212] 302. In response to an operation triggered by the user through the interactive interface, send a log file list acquisition request to the first device selected by the user for log reporting;

[0213] 303. According to the log file list fed back by the received first device, send a file information acquisition request to the first device;

[0214] 304. In response to a communication connection request sent by the target second device, establish a communication connection with the target second device and disconnect the communication connection with the first device;

[0215] 305. Receive the file information of the second compressed log file in the target second device sent by the target second device;

[0216] 306. Perform the sub-packet collection operation of the second compressed log file on the target second device according to the file information of the second compressed log file and the log file transmission parameters;

[0217] Among them, the first device communicates with at least one second device in a master-slave manner. The log file list is generated by the first device according to the file names of the first compressed log files in the first device and the file names of the second compressed log files in the at least one second device; the target second device is one of the at least one second devices; the target second device sends a communication connection request to the third device according to the communication connection information between the first device and the third device sent by the first device received; the first device sends the communication connection information to the target second device when performing master-slave switching with the target second device when it is determined that the file name specified in the received file information acquisition request carries the device identifier of the target second device.

[0218] In the above 301-302, the interactive interface may refer to the problem feedback interface provided by the log collection application (such as the intelligent space application) on the third device, as Figure 7 shown. Through this interactive interface, the user can trigger a problem feedback operation to select the device for which problem feedback is required (i.e., the device for which log reporting is required), input a device problem description, etc. For the specific description implementation of the user's operation on this interactive interface, reference can be made to the relevant content in other embodiments of this application.

[0219] For the specific implementation description of the above steps 303-306, reference can also be made to the relevant content in other embodiments of this application.

[0220] In the above step 306, the file information of the second compressed log file includes: total file size, check information, and the check information is used for the third device to check the collected second compressed log file. The log file transmission parameters include: maximum transmission length, frame length of frame logs, transmission interval duration, retransmission support situation; the maximum transmission length is equal to the frame length multiplied by the maximum number of consecutive frame logs that can be transmitted for a single log data acquisition request. For the specific details of the log file transmission parameters, reference can be made to the relevant content in other embodiments of this application.

[0221] Further, when the retransmission support situation included in the above log file transmission parameters is to support bitmap-based log retransmission, the above step 306 "Perform the sub-packet collection operation of the second compressed log file on the target second device according to the file information of the second compressed log file and the log file transmission parameters" may include the following steps:

[0222] 3061. Send a log data acquisition request to the target second device according to the file information of the second compressed log file and the log file transfer parameters; wherein, the parameters carried in this log data acquisition request (hereinafter referred to as this request) include: the starting offset, data size, and frame log bitmap of the target packet log data requested, and the frame log bitmap indicates that some frame logs in the target packet log data of this request need to be retransmitted or indicates that all frame logs in the target packet log data of this request need to be uploaded;

[0223] 3062. Receive the frame logs sent by the target second device in response to this request;

[0224] 3063. Determine the frame number of the received frame logs according to the information carried in the received frame logs;

[0225] 3064. Set the value of the bit corresponding to the frame number of the received frame logs in the frame log bitmap corresponding to this request to the received value (for example, set it to the first numerical value, such as 1);

[0226] 3065. When it is time to send the next log data acquisition request, determine the parameters to be carried in the next request according to the frame log bitmap corresponding to this request until the collection of the second compressed log file is completed.

[0227] In the above 3065, the time to send the next log data acquisition request includes: when no frame logs are received after the waiting duration exceeds the transmission interval duration; and / or, the number of received frame logs reaches the maximum number of frames that can be continuously sent for a log data acquisition request.

[0228] In a specific implementable solution, the above 3065 "determine the parameters to be carried in the next request according to the frame log bitmap corresponding to this request" may include the following steps:

[0229] 30651. Determine whether there are lost frames in the target packet log data requested according to the frame log bitmap corresponding to this request;

[0230] 3065. When there are lost frames, respectively determine the starting offset, data size, and frame log bitmap of the target packet log data of this request as the daily starting offset, data size, and frame log bitmap of the target packet log data to be carried in the next request;

[0231] When there is no frame loss, the sum of the starting offset and the data size of the target packet log data requested this time is determined as the starting offset of the target packet log data to be carried in the next request; all the values corresponding to the bits in the frame log bitmap to be carried in the next request are values indicating not received (for example, all are the second value, such as 0), the data size is the maximum transmission length or the difference between the total file size of the second compressed log file and the sizes of all received packet log data. Specifically, in the case where the total file size cannot be evenly divided by the maximum transmission length, if the target packet log data for the next request is the last packet log data in the second compressed log file (that is, the last packet log data in the queue), the data size to be carried in the next request is the difference between the total file size of the second compressed log file and the sizes of all received packet log data; conversely, if the target packet log data for the next request is not the last packet log data in the second compressed log file, the data size to be carried in the next request is the maximum transmission length.

[0232] For the specific implementation descriptions of the steps in the method provided in this embodiment above, reference can be made to the relevant content in other embodiments of this application, and specific details will not be elaborated here. In addition, the method provided in this embodiment may further include other steps in addition to the steps given above. For the other steps that may be included and their specific implementation descriptions, reference can also be made to the relevant content in other embodiments of this application.

[0233] Two other embodiments of this application provide a log reporting method. The execution subject of all steps in the method provided by these two embodiments can be the first device in the above system. More specifically, it can be executed by the service component (WearSDK) in the first device. The first device is in communication connection with the third device, and the third device is used for log file collection. For the detailed descriptions of the first device and the third device and the description of the communication method, reference can be made to the relevant content in other embodiments of this application. Specifically, the log reporting methods provided by the other two embodiments of this application are as follows:

[0234] As shown in Figure 11 , a log reporting method provided by an embodiment includes the following steps:

[0235] 401. Receive a log data acquisition request sent by the third device for the first compressed log file in the first device; wherein, the log data acquisition request carries the starting offset, data size, and frame log bitmap of the target packet log data requested; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or indicates that all frame logs in the target packet log data need to be uploaded;

[0236] 402. Obtain the target packet log data from the multi-packet log data included in the first compressed log file according to the starting offset and the data size;

[0237] 403. If the frame log bit map indicates that some frames in the target packet log data need to be retransmitted, determine the frame numbers of the frames to be retransmitted according to the frame log bit map; selectively retransmit multiple frames in the target packet log data to the third device according to the frame numbers and the negotiated frame length;

[0238] 404. If the frame log bit map indicates that all frames in the target packet log data need to be uploaded, transmit multiple frames in the target packet log data frame by frame to the third device.

[0239] Further, the method provided in this embodiment further includes the following steps:

[0240] 400a. Receive a negotiation request sent by the third device; the negotiation request carries log file transfer parameters;

[0241] 400b. Send the negotiation result of the log file transfer parameters to the third device, so that the third device sends a log data acquisition request to the first device for the first compressed log file according to the negotiated log file transfer parameters and the file information of the obtained first compressed log file;

[0242] Among them, the log file transfer parameters include at least one of the following: maximum transfer length, frame length of frame logs, transfer interval duration, retransmission support request; the maximum transfer length is equal to the frame length multiplied by the maximum number of consecutive frames that can be transferred for a single log data acquisition request; when the retransmission support request is to support bitmap-based log retransmission, the log data acquisition request sent by the third device carries a frame log bit map.

[0243] For the specific implementation descriptions of the steps in the method provided in this embodiment above, reference can be made to the relevant content in other embodiments of this application, and no specific elaboration will be made here. In addition, in addition to the steps given above, the method provided in this embodiment may further include other steps. For the other steps that may be included and their specific implementation descriptions, reference can also be made to the relevant content in other embodiments of this application.

[0244] Such as referring to Figure 12 , the log reporting method provided in another embodiment includes the following steps:

[0245] 501. Obtain the logs generated by the application on the first device;

[0246] 502. Hash the logs generated by the application to obtain the hashed logs.

[0247] 503. Write the hashed logs into the log file corresponding to the application.

[0248] 504. When it is detected that the condition for reporting the log file to the third device is met, compress all the log files in the first device together to obtain a first compressed log file.

[0249] 505. Send the file information of the first compressed log file to the third device for the third device to perform the sub-packet collection operation of the first compressed log file on the first device according to the file information.

[0250] Further, the above first device is also connected to at least one second device for master-slave communication, and the first device is the master device in the master-slave communication connection; and when it is detected that the condition for reporting the log file to the third device is met, the method provided in this embodiment further includes the following steps:

[0251] A11. Send notifications to the at least one second device respectively to notify the preparation for reporting the log file.

[0252] A12. Receive the file names of the second compressed log files sent by the at least one second device respectively.

[0253] A13. Generate a log file list according to the file name of the first compressed log file and the received file names of the second compressed log files.

[0254] A14. Send the log file list to the third device.

[0255] Among them, the file name of the first compressed log file carries the device identifier of the first device; the second compressed log file is obtained by compressing all the log files in the corresponding second device in response to the notification; the file name of the second compressed log file carries the device identifier of the corresponding second device.

[0256] Further, in a specific implementation solution, in step 505 above, "send the file information of the first compressed log file to the third device" includes:

[0257] 5051. In response to the file information acquisition request sent by the third device according to the log file list, determine the file name specified by the request.

[0258] 5052. If the specified file name contains the device identifier of the first device, obtain the file information of the first compressed log file and send the file information of the first compressed log file to the third device;

[0259] Among them, the file information of the first compressed log file includes: the total file size and the verification information, which is used for the third device to verify the second compressed log file collected.

[0260] For the specific implementation descriptions of the steps in the method provided in this embodiment above, reference can be made to the relevant content in other embodiments of this application, and no specific elaboration will be made here. In addition, the method provided in this embodiment may further include other steps in addition to the steps given above. For the other steps that may be included and the specific implementation descriptions, reference can also be made to the relevant content in other embodiments of this application.

[0261] In summary, the log reporting technical solution provided in this application can be briefly described as follows:

[0262] 1. For the problem of time-consuming log file reporting, the technical solution adopted in this application is as follows:

[0263] 1.1 Introduce the hash and compression scheme for logs into WearSDK to reduce the log size. Specifically:

[0264] See Figure 5 , for the logs generated by the Bluetooth thin device for its applications 1 to N (including the business applications of WearSDK on the Bluetooth thin device (such as log service applications, other types of business service applications), and other types of business applications such as communication modules (such as Bluetooth modules)), the Bluetooth thin device will write the hashed logs into the corresponding application's hash log file through the log API interface with hash function in the Bluetooth thin device. Further, after the Bluetooth rich device triggers the log reporting process, WearSDK on the Bluetooth thin device will receive the log reporting request from the Bluetooth rich device (the log file list acquisition request described in the context), and notify the compression module in the log service in WearSDK on the Bluetooth thin device to execute the compression action of the log file, compress the hash log files 1 to N into a log file.zip (the first compressed log file) and output it; furthermore, through WearSDK and the Bluetooth module on the Bluetooth thin device, the output log file.zip will be reported to the Bluetooth rich device and finally transmitted to the corresponding APP (the log collection application, such as the smart space application) on the Bluetooth rich device for subsequent processing.

[0265] 1.2 Introduce a master-slave switching mechanism in the master-slave device log reporting scenario. See Figure 4b Specifically as follows:

[0266] 1) The APP (log collection application) on the Bluetooth rich device triggers the log reporting process. Specifically, when the user encounters an abnormality during the use of the Bluetooth lean device (including the Bluetooth master device (referred to as the master device for short) and the Bluetooth slave device (referred to as the slave device for short, such as slave device 1 and slave device 2)), the user can check the Bluetooth lean devices for which problems need to be reported at the APP problem feedback entry, fill in the description of the problems that occurred with the specific Bluetooth lean devices, etc., and click Confirm after filling in; in response to this confirmation operation, the APP will send a request for device logs (a request for a list of log files) to the Bluetooth lean device side (send it to the master device) through the Bluetooth module on the Bluetooth rich device.

[0267] 2) The Bluetooth module in the Bluetooth rich device communicates with the Bluetooth module in the Bluetooth master device. Before the Bluetooth rich device and the Bluetooth master device perform the log file collection interaction, the user has already performed a pairing connection operation on the two, and at this time, the Bluetooth rich device and the Bluetooth master device can provide a stable Bluetooth transmission channel for the log reporting service. Before the APP on the Bluetooth rich device interacts with the WearSDK on the Bluetooth master device, it will create a UUID Bluetooth service channel of XXXX for the log reporting service.

[0268] 3) The Bluetooth master device receives the data and sends it to the WearSDK on it. After the Bluetooth master device receives the binary byte stream of the file information acquisition request instruction transmitted by the Bluetooth rich device, it will pass the binary byte stream data to the WearSDK on it through the external interface provided by the WearSDK on it.

[0269] 4) The WearSDK on the Bluetooth master device parses the data and processes the corresponding requests or responses. After the WearSDK on the Bluetooth master device receives the binary byte stream data sent by the Bluetooth master device through its Bluetooth module, it will perform internal private related protocols (such as the MBB protocol) parsing, identify the specific service type (log service) and request type (log file information), and parse out the file name information of the request. For example, the file name information is xxx_master.log; identifying that the file name contains the master field indicates that it is a request for the log of the Bluetooth master device. At this time, it will directly obtain the total file size and checksum information (used for the Bluetooth rich device to verify the collected log files) and other file information of the internal log files from the Bluetooth master device, and return the file information to the APP on the Bluetooth rich device through the 4-3-2-1 transmission path. Then, the APP will request the log file content from the Bluetooth master device through the 1-2-3-4 transmission path according to the received file information. After the WearSDK on the Bluetooth master device receives the log file content request, it will report the log file content to the APP on the Bluetooth rich device through the 4-3-2-1 transmission path.

[0270] 5.1) Device role switching between the Bluetooth master and slave devices. If the WearSDK on the Bluetooth master device in the above 4) parses the requested file name information, such as xxx_slave1.log, and identifies the slave1 field in the file name for this file name information, it indicates that the current request is for the log of Bluetooth slave device 1. At this time, the WearSDK on the Bluetooth master device will call the interface provided by the Bluetooth master device to inform the Bluetooth master device to perform the master-slave device role switching. As a result, the Bluetooth master device will send its pairing information with the Bluetooth rich device (which is the communication connection information) to Bluetooth slave device 1, enabling Bluetooth slave device 1 to pair and connect with the Bluetooth rich device based on the received pairing information. After the successful master-slave device role switching, Bluetooth slave device 1 becomes the new Bluetooth master device to conduct log reporting service interactions with the Bluetooth rich device, and the device is prohibited from spontaneously performing master-slave device role switching during the log reporting service interaction process. The original Bluetooth master device will disconnect the pairing connection with the Bluetooth rich device and become Bluetooth slave device 1. A new Bluetooth transmission channel is established between the APP on the Bluetooth rich device and the Bluetooth module on the new Bluetooth master device for subsequent log reporting interactions.

[0271] 5.2) The new Bluetooth master device receives data and sends it to the WearSDK on it. The specific implementation is the same as described in the above 3).

[0272] 5.3) The WearSDK on the new Bluetooth master device parses the data and processes the corresponding requests or responses. The specific implementation is the same as described in the above 4), but at this time the log file reporting process becomes 1-5-6-7;

[0273] 6.1) Device role switching between the Bluetooth master and slave devices. If the WearSDK on the Bluetooth master device in the above 4) parses the requested file name information, such as xxx_slave2log, and at this time, for this file name information, it will identify the slave2 field in the file name, indicating that the current request is for the log of Bluetooth slave device 2. At this time, the WearSDK on the Bluetooth master device will call the interface provided by the Bluetooth master device to inform the Bluetooth master device to perform the master-slave switching. As a result, the Bluetooth master device will send its pairing information with the Bluetooth rich device (which is the communication connection information) to Bluetooth slave device 2, enabling Bluetooth slave device 2 to pair and connect with the Bluetooth rich device based on the received pairing information. After the successful master-slave device role switching, Bluetooth slave device 2 becomes the new Bluetooth master device to conduct log reporting service interactions with the Bluetooth rich device, and the device is prohibited from spontaneously performing master-slave device role switching during the log reporting service interaction process. The original Bluetooth master device will disconnect the pairing connection with the Bluetooth rich device and become Bluetooth slave device 2. A new Bluetooth transmission channel is established between the APP on the Bluetooth rich device and the Bluetooth module on the new Bluetooth master device for subsequent log reporting interactions.

[0274] 6.2) The new Bluetooth master device receives data and sends it to the WearSDK on it. The specific implementation is the same as described in 3) above.

[0275] 6.3) The WearSDK on the new Bluetooth master device parses the data and processes the corresponding requests or responses. The specific implementation is the same as described in 4) above, but at this time, the process of reporting the log file becomes 1-8-9-10;

[0276] In summary, in the scenario of log reporting for master and slave devices, by introducing the master-slave device role switching scheme, compared with the existing technical solution, this solution can reduce the steps of the slave device log reporting process and achieve the effect of having the same number of steps as the master device log reporting process.

[0277] 2. To address the problem of possible frame loss during the log file reporting process, the technical solution adopted in this application is to introduce a log retransmission mechanism based on a bitmap (bitmap). The specific implementation is as follows:

[0278] As shown in Figure 8, the Bluetooth low device side will divide the log file (more specifically, the compressed log file obtained by compression) into N packets of log data (Package1 to PackageN). During the log reporting service interaction, the APP on the Bluetooth high device requests 1 packet of log data each time. Correspondingly, the Bluetooth low device responds to the request and returns the corresponding 1 packet of log data. Among them, 1 packet of log data contains multiple frames of logs (such as 8 frames of logs or 16 frames of logs). The specific number of frame logs contained in 1 packet of log data is determined by the WearSDK manufacturer according to the size of the buffer sent by the Bluetooth module. If the buffer is relatively large, 16 frames can be selected; otherwise, 8 frames are selected. This application will be described with 8 frames. After receiving the request for obtaining 1 packet of log data sent by the APP on the Bluetooth high device, the Bluetooth low device will continuously send the corresponding 8 frames of logs to the APP. Among them, according to the internal private related protocol such as the MBB protocol, each frame of log will carry a psn field, which is used to indicate which frame of log is currently being sent. After receiving each frame of log, the APP can set the value of the corresponding bit in the corresponding bitmap to 1 according to the psn information carried by the frame of log, indicating that the current frame of log has been received. The bitmap shown in Table 2 indicates that in the interaction of this request for 1 packet of log data, the 4th frame of log and the 6th frame of log in the requested 1 packet of log data have not been received. Further, based on the bitmap information shown in Table 2, when the APP on the Bluetooth high device makes the next request to obtain 1 packet of log data, the bitmap information shown in Table 2 will be carried in the next request, and the start offset and data size of the 1 packet of log data requested in the next request will be set to the start offset and data size of the 1 packet of log data requested in the previous request. After receiving the next request, the Bluetooth device can know which frame logs were lost during the log transmission for the previous log data acquisition request based on the start offset and bitmap information carried in the request, and thus can quickly resend the lost frame logs to the APP on the Bluetooth high device when responding to this next request.

[0279] The following will introduce the solution of this application in combination with a specific application scenario for better understanding of the solution of this application. During the following introduction of the solution of this application, it will be described by taking the Figure 13a and Figure 13b shown log reporting timing flow diagram as an example, with the high device being a mobile phone and the low device being a master-slave Bluetooth headset. Among them, the Bluetooth headset includes two earbuds, namely the left earbud and the right earbud. Generally, the left earbud is the master earbud (i.e., the master device) and the right earbud is the slave earbud (i.e., the slave device). When the mobile phone pairs and connects with the Bluetooth headset through the Bluetooth module, it pairs and connects with the left earbud, and the left earbud then pairs and connects with the right earbud. During Figure 13a and Figure 13bIt is mainly divided into two parts: the master and slave devices (the left and right earphones of the Bluetooth headset) report logs to the mobile phone. The process steps starting with the serial number M are mainly the interaction steps between the mobile phone and the left earphone. The process steps starting with the serial number D are mainly the interaction steps between the left and right earphones. The process steps starting with the serial number S are mainly the interaction steps between the mobile phone and the right earphone. The process steps starting with the serial number M' are the interaction steps between the mobile phone and the new master device (the original slave device (right earphone) is switched to the new master device). The process steps starting with the serial number S' are mainly the interaction steps between the mobile phone and the new slave device (the original master device (left earphone) is switched to the new slave device). The interaction processes of these two parts, namely, the mobile phone and the new master device, and the mobile phone and the original master device, are independent and decoupled from each other, but the interaction processes with the mobile phone are the same.

[0280] Such as Figure 13a and Figure 13b , the log reporting process provided by this application is specifically as follows:

[0281] 1. Log generation stage

[0282] M1: The mobile phone and the left earphone establish a normal pairing connection. Specifically, a Bluetooth pairing connection is established based on the Bluetooth protocol.

[0283] D1: The left earphone and the right earphone establish a pairing connection, which is a master-slave pairing connection. Specifically, a Bluetooth pairing connection is established based on the Bluetooth protocol. Among them, the left earphone is the master device, and the right earphone is the slave device.

[0284] M2: The mobile phone and the left earphone perform interactions for non-log reporting services, such as device registration, power reporting, information query, etc. During the service interaction process, the corresponding registration module, device management module, etc. on the mobile phone will generate service logs, and the corresponding service modules on the left earphone side (such as the service applications corresponding to the WearSDK on it) will also generate corresponding log information.

[0285] D2: Interaction between the master and slave devices. After the left and right earphones are paired and connected, the left earphone will synchronize some information, such as time information, to the right earphone for storage through the master-slave transmission channel (master-slave Bluetooth transmission service channel) established during the pairing connection in step D1 (this is step D2.1 in Figure 13). During this synchronization process, the relevant data receiving and sending modules of the WearSDK on the right earphone (as the Bluetooth slave device) and the corresponding data receiving / sending modules of the speaker (as the Bluetooth master device) will generate relevant log information.

[0286] 2. Hash processing stage of the original log

[0287] M3: Log Hash processing of the master device. For the original logs generated in steps M2 and D2, the left earphone will perform Hash processing on the original logs through the Hash log API with Hash function on it, and write the logs after Hash processing into the corresponding log files for storage through step M3.1;

[0288] S1: Log Hash processing of the slave device. For the original logs generated in step D2.1, the right earphone will perform Hash processing on the original logs through the Hash log API on it, and write the logs after Hash processing into the corresponding log files for storage through step S1.1.

[0289] 3. Log file reporting stage

[0290] In the smart space application (hereinafter directly referred to as APP) installed on the user's mobile phone, the user clicks on problem feedback to report problems that occur during the use of the Bluetooth headset. After the user fills in information such as problem description and occurrence probability, clicking submit will trigger the process for the APP to collect the logs on the Bluetooth headset side. Specifically as follows:

[0291] M4: The APP on the mobile phone sends a log file list acquisition request to the left earphone. Based on an internal private related protocol, such as the MBB protocol, the APP encapsulates the log file list acquisition request information into a protocol message, and then sends the protocol message (which is the log file list acquisition request information) to the left earphone through the Bluetooth module on the mobile phone;

[0292] M4.1: The WearSDK on the left earphone parses the received protocol message (log file list acquisition request) and notifies the right earphone to prepare to report the log file. Specifically, after the Bluetooth module on the mobile phone sends the protocol message to the left earphone, it will first be received by the Bluetooth module on the left earphone and passed to the WearSDK on the left earphone. After the WearSDK on the left earphone receives the protocol message, it will parse the protocol message based on an internal private related protocol (such as the MBB protocol), and after confirming that the protocol message is a log file list acquisition request, it will synchronously inform the right earphone of the log file list acquisition request information through the external interface.

[0293] D3: The left earphone synchronizes the log file list request information to the right earphone. After the WearSDK on the left earphone receives the information of the log file list acquisition request, it will synchronize the information of the log file list acquisition request to the right earphone through the master-slave transmission channel established in step D1 to notify the right earphone to prepare to report the log file (corresponding to step S2 in Figure 13);

[0294] S2.1: The right earphone compresses the log files therein. After the right earphone receives the log file list acquisition request synchronized from the left earphone, the log service in its WearSDK (i.e., the log service module in the figure, also known as the device log management service module) will initiate the log file compression action, compressing multiple log files (slave ear log files) in the right earphone into one compressed log file, such as xxx_slave.zip file (this is an example of using the zip method for compression (the suffix of the generated compressed log file is.zip). Without special instructions later, the compression involved is also in the zip method). The WearSDK integrated development document stipulates that the device log of the slave device carries the slave field, and the compression suffix name is the suffix name of the regular compression format;

[0295] S2.2: Report the file name of the log file in the right earphone. After the right earphone finishes compressing the log files therein, it will synchronize the file name xxx_slave.zip of the corresponding generated compressed log file to the left earphone through the master-slave transmission channel established in step D1 (i.e., step D3.2 in Figure 13);

[0296] M4.2: The left earphone compresses the log files therein. After the left earphone receives the log file list request, the log service in its WearSDK (i.e., the log service module in the figure, also known as the device log management service module) initiates the log file compression action, compressing multiple log files (master ear log files) in the left earphone into one compressed log file, such as xxx_master.zip file (this is an example of using the zip method for compression (the suffix of the generated compressed log file is.zip)). The WearSDK integrated development document stipulates that the log of the Bluetooth master device (left earphone) carries the master field, and the compression suffix name is the suffix name of the regular compression format;

[0297] M4.3: Return the log file lists of the left earphone and the right earphone to WearSDK. The log service in the WearSDK on the left earphone separates the file name of the compressed log file in the left earphone and the file name of the log file received from the right earphone with a semicolon ";", forming the following log file list: xxx_master.zip; xxx_slave.zip, and returns this log file list to the WearSDK on the left earphone;

[0298] M4.4: Respond to the log file list acquisition request sent by the APP on the mobile phone. The WearSDK on the left earphone encapsulates the log file list information obtained through step M4.3 based on the internal private related protocol (MBB protocol) and sends it to the APP on the mobile phone through the Bluetooth module on the left earphone;

[0299] M5: Negotiate log file transfer parameters. The APP on the mobile phone negotiates with the left earphone the log file transfer parameters for uploading the log file from the earphone device to the mobile phone. The log file transfer parameters include the maximum transfer length allowed for the APP to apply, the frame length (i.e., frame size) of each frame of the log, the transfer interval duration, whether retransmission is supported, the protocol version, etc. After receiving the negotiation parameter request information sent by the APP, the left earphone hands it over to the WearSDK on it for protocol parsing and reports the negotiation result to the APP (corresponding to step M5.1 in the figure). Among them, the maximum transfer length allowed for the APP to apply = the frame length of the frame log * the maximum number of consecutive frames that can be transmitted for a single log data acquisition request (such as 8 frames or 16 frames); whether retransmission is supported refers to whether the selective retransmission function based on bitmap is supported;

[0300] M6: Obtain single file information (i.e., obtain the file information of a single log file). The APP sends a file information acquisition request to the left earphone according to the received log file list. The file information acquisition request carries the specified file name. If the specified file name is, for example, xxx_master.zip, it means that the file information of the compressed log file in the left earphone needs to be requested to obtain the total file size of the compressed log file in the left earphone. After receiving this file information acquisition request, the left earphone hands it over to the WearSDK on it for protocol parsing. After confirming that it is a request for the file information of the log file in the left earphone, it queries the total file size and other information of the compressed log file in the left earphone through the log service in step M6.1, and then reports the query result to the APP on the mobile phone through steps M6.2 and M6.3;

[0301] M7: Request log file data. After the APP on the mobile phone receives information such as the total file size of the compressed log file in the left earphone, it will negotiate transmission parameters (i.e., the negotiated log file transmission parameters) with the first device through step M5, and based on the result of the negotiated transmission parameters (corresponding to step M5.1 response in the figure, indicating the result of the transmission parameter negotiation returned by the left earphone), send a log data acquisition request to the left earphone. Specifically, if it is determined through negotiation that the earphone device supports retransmission, when the APP on the mobile phone sends a log data acquisition request to the left earphone, it will make the request carry a bitmap field (frame log bitmap field, and all the values of the bits in the bitmap carried in the first request are 0, indicating that each frame of the log data in a requested packet of log data needs to be uploaded); at the same time, it will also make the request carry the starting offset and data size of a requested packet of log data. The value of the data size is generally the maximum transmission length allowed for the APP to apply through negotiation in step M5. Since the total file size may not be divisible by the maximum transmission length allowed for the APP to apply through negotiation in step M5, in this scenario, when the log data acquisition request requests the last packet of log data in the compressed log file of the left earphone, the value of the data size will be less than the maximum transmission length allowed for the APP to apply through negotiation in M5 (the value of the data size = the total file size of the compressed log file in the left earphone minus the size of the log data that has been reported in the compressed log file in the left earphone). After receiving the log acquisition request, the left earphone sends the requested packet of log data in the compressed log file in the left earphone frame by frame to the APP on the mobile phone based on the starting offset, data size, and frame length negotiated in step M5 (corresponding to Figure 13a steps M7.2 - M7.5 in it). During the process of the APP on the mobile phone receiving the frames of logs sent by the left earphone, it will set the value of the corresponding bi5 bit in the corresponding bitmap to 1 (indicating that the corresponding frame of log has been received). When the 7th frame of log is received or the reception timeout (exceeding the negotiated transmission interval duration) occurs, it will trigger the process of the next packet of log data acquisition request.

[0302] M7.6&M7.7: The APP on the mobile phone requests the next packet of log data from the left earphone. The APP collects the previous packet of log data through the above step M7 and records the collection situation of the previous packet of log data through the corresponding bitmap. Based on the situation of the bit values in the bitmap obtained through the above step M7, the starting offset carried in this request will be different. Specifically as follows:

[0303] If all the bit values in the bitmap obtained through the above step M7 are 1, it indicates that all the frame logs sent by the left earphone during the previous packet of log data request have been received normally without frame loss. The starting offset carried in this request = the starting offset carried in the previous request + the data size carried in the previous request. The carried bitmap has all bit values of 0 (indicating that this request is for a new packet of log data). The carried data size is the same as the data size strategy described in the above step M7, and when requesting non-last packet of log data, it is the maximum transmission length allowed by the APP.

[0304] If the bit values in the bitmap obtained through the above step M7 are not all 1, it indicates that there is frame loss. The starting offset carried in this request = the starting offset carried in the previous request. The carried bitmap is the bitmap obtained through the above step M7, indicating that selective retransmission of the frame logs in a packet of log data in the previous request is required. The carried data size = the data size carried in the previous request.

[0305] After the left earphone receives the request for the next packet of log data sent by the APP, if it is a request for a new packet of log data, it reports frame by frame according to the above step M7 (see steps M7.9 - 7.12 shown in Figure 13). If it is a selective retransmission, the left earphone, based on the bitmap information carried in this request, re-sends the frames corresponding to the bit values of 0 in the bitmap to the APP on the mobile phone (see Figure 13a the steps M7.9 - 7.12 shown in

[0306] Loop the above M7.6 - M7.12 until the reporting of the compressed log file in the left earphone is successfully completed (i.e., the mobile phone successfully collects the compressed log file of the left earphone).

[0307] M8: The mobile phone requests to obtain another single file information (i.e., requests the file information of the next log file in the log file list). After the reporting of the previous log file (the compressed log file xxx_master.zip in the left earphone) is completed, the APP on the mobile phone continues to take out the next file name such as xxx_slave.zip from the log file list and sends a corresponding file information acquisition request to the left earphone. After the left earphone receives this file information acquisition request, it hands it over to the WearSDK on it for parsing;

[0308] M8.1: Confirm whether master-slave switch is needed. After step M8.1, it is parsed that the file name specified in the received file information acquisition request contains the "slave" field, indicating that the APP is requesting the file information of the compressed log file in the right earphone. At this time, the WearSDK on the left earphone uses the master-slave transmission channel established in step D1 to tell the right earphone the current log reporting status (the file information waiting to be reported status) so as to be saved in the WearSDK on the right earphone (corresponding to Figure 13b the step M8.2 shown in

[0309] ). Meanwhile, the WearSDK on the left earphone will also call the interface provided on the main left earphone to inform the left earphone to perform the master-slave device role switch (step M8.3), and the left earphone will send its pairing information with the mobile phone (the communication connection information) to the right earphone through the master-slave transmission channel (step M8.4);

[0310] M’1: The right earphone establishes a connection with the mobile phone. After receiving the pairing information between the left earphone and the mobile phone, the right earphone initiates a pairing connection request to the mobile phone and establishes a pairing connection;

[0311] S’1: The left earphone disconnects from the mobile phone. After the mobile phone establishes a connection with the right earphone, it will disconnect from the left earphone;

[0312] M’2: Prevent spontaneous master-slave switch between devices. After the above steps M’1 and S’1, the right earphone switches to the new master device to interact with the mobile phone for log file reporting, and the left earphone switches to the slave device (the slave device of the right earphone, only connected to the right earphone). To prevent the master-slave device switch from occurring again during the process of the right earphone interacting with the mobile phone for log reporting (transmitting and interacting with the compressed log file xxx_slave.zip of the right earphone), such as the spontaneous switch logic caused by the change of the master-slave device power, after the WearSDK on the left earphone calls the interface provided on it through step 8.3 for the master-slave role switch and the right earphone and the mobile phone establish a connection, the right earphone will prevent spontaneous master-slave switch between devices;

[0313] M’2.2: Report the successful status of master-slave device role switch. After the right earphone and the mobile phone establish a connection, it will report the current device role status of the right earphone to the WearSDK on it. The WearSDK on it can know that it is currently in the process of waiting to report the file information of the log file through the current log reporting status saved in step M8.2 (step M’2.3);

[0314] M’4: Log file data acquisition. This step M’4 is the same as that described in step M7 above;

[0315] M’5: Log file collection completion stage. After the APP on the mobile phone completes the collection of the compressed log files in the right earphone, that is, the collection of all files in the log file list is completed. At this time, the APP will tell the right earphone the result of successful collection (step M’5.1). After being parsed by WearSDK on the right earphone, the result information will be told to the device side of the right earphone through the interface provided by the log service on the right earphone (step M’5.2). After the right earphone senses that the log file transmission is completed, it releases the prohibition of spontaneous master-slave switching between devices.

[0316] In summary, the technical solutions provided by this application have the following benefits:

[0317] 1) Introducing the Hash and compression schemes for logs into WearSDK can significantly reduce the size of log files. After actual measurement of a certain product, the size of the log without Hash is about 13.3M, while the log after Hash is about 3.78M, and the size is reduced by about 78%; in addition, if the log before compression is 3.78M, the log after compression can reach 1.81M, and the size will be reduced by about 47.9% again.

[0318] 2) In the scenario of master-slave device log reporting, a master-slave role switching scheme before slave device log reporting is introduced, reducing the main process of uploading slave device logs from 6 steps to 4 steps in the existing scheme. After actual measurement of a certain product, using the existing scheme, it takes about 10ms for the log service on WearSDK to obtain the master device log, and the time to obtain the slave device log ranges from about 30 - 50ms. However, when using the scheme provided by this application for log reporting, the slave device log reporting time can be reduced by about 50%;

[0319] 3) Introducing a selective retransmission mechanism in the log reporting process. Based on the bit information recorded in the bitmap, it can be known which frames of logs are lost in a single request transmission, so that the lost frame logs can be quickly resent to the mobile phone in the next request. At the same time, the interception of cyclic requests for a packet of log data with the same starting offset is increased, and a policy of not processing when the number of requests for a packet of log data with the same starting offset exceeds a preset number (such as 3 times) is set.

[0320] The following several embodiments of this application also provide a log reporting device corresponding to each of the above method embodiments. Specifically:

[0321] Figure 14The figure shows a schematic structural diagram of a log reporting device provided by an embodiment of the present application. The device is deployed on a first device. The first device is a master device and communicates with at least one second device in a master-slave manner. The first device also communicates with a third device having a log file collection function. As shown in Figure 14 , the log reporting device provided in this embodiment includes: a generation module 61, a sending module 62, a determination module 63, and an execution module 64. Among them, the generation module 61 is configured to generate a log file list according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device when it is detected that the condition for reporting the log file to the third device is met; the sending module 62 is configured to send the log file list to the third device; the determination module 63 is configured to determine the file name specified by the request in response to a file information acquisition request sent by the third device according to the log file list; the execution module 64 is configured to, if the specified file name carries the device identifier of the target second device, perform a master-slave switch with the target second device, so that the target second device switches to be the master device and communicates with the third device, so as to send the file information of the second compressed log file in the target second device to the third device, for the third device to perform a sub-packet collection operation on the second compressed log file of the target second device according to the received file information; where the target second device is one of the at least one second device.

[0322] Further, when the execution module 64 is used to perform a master-slave switch with the target second device, it is specifically configured to: send the communication connection information between the first device and the third device to the target second device, so that the target second device establishes a communication connection with the third device according to the communication connection information, and after establishing a communication connection with the third device, prohibit the target second device from spontaneously performing a master-slave switch; disconnect the communication connection with the third device.

[0323] Further, when the specified file name carries the device identifier of the target second device, the device provided in this embodiment further includes: sending a reporting status notification to the target second device to inform the target second device that the current log file reporting status is the status of waiting for the file information of the second compressed log file to be reported.

[0324] Further, the above-mentioned sending module is further configured to separately send notifications to the at least one second device to notify them to prepare for reporting log files; and, the apparatus provided in this embodiment further includes: a compression module, configured to compress a plurality of log files in the first device together to obtain the first compressed log file; the file name of the first compressed log file carries the device identifier of the first device; a receiving module, configured to receive the file names of the second compressed log files separately sent by the at least one second device; wherein, the second compressed log file is obtained by the second device compressing a plurality of log files in the second device together in response to the notification; the file name of the second compressed log file carries the device identifier of the second device.

[0325] Further, the apparatus provided in this embodiment further includes: an obtaining module, configured to obtain the logs generated by the application on the first device; a processing module, configured to perform hash processing on the logs generated by the application to obtain the hashed logs; a writing module, configured to write the hashed logs into the log file corresponding to the application.

[0326] Further, the apparatus provided in this embodiment further includes: a sub-packaging module, configured to divide the first compressed log file into multiple packets of log data, so as to subsequently report the first compressed log file in packets to the third device; wherein, one packet of log data contains multiple frames of logs.

[0327] Further, the above-mentioned sending module 62 is further configured to, if the specified file name carries the device identifier of the first device, send the file information of the first compressed log file to the third device, so that the third device performs the sub-packet collection operation of the first compressed log file on the first device according to the file information of the first compressed log file and the log file transmission parameters negotiated with the first device; wherein, the file information includes: the total file size, verification information, and the verification information is used for the third device to verify the collected first compressed log file; the log file transmission parameters include at least one of the following: the maximum transmission length, the frame length of the frame log, the transmission interval duration, and the retransmission support situation; the maximum transmission length is equal to the frame length multiplied by the maximum number of consecutive frames of frame logs that can be transmitted for a single log data acquisition request.

[0328] Further, the retransmission support scenario is to support bitmap-based log retransmission; and, the above receiving module is further configured to receive a log data acquisition request sent by the third device for the first compressed log file; wherein, the log data acquisition request carries the start offset, data size, and frame log bitmap of the target packet log data requested; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or indicates that all frame logs in the target packet log data need to be uploaded; the target packet log data is one packet of log data included in the multiple packet log data included in the first compressed log file; the above acquisition module is further configured to acquire the target packet log data from the multiple packet log data included in the first compressed log file according to the start offset and the data size; the above determination module is further configured to, if the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted, determine the frame numbers of the frame logs that need to be retransmitted according to the frame log bitmap; the above sending module 62 is further configured to selectively retransmit multiple frame logs in the target packet log data to the third device according to the frame numbers and the negotiated frame length, and is further configured to, if the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded, transmit multiple frame logs in the target packet log data to the third device frame by frame.

[0329] Further, the above determination module 63 is further configured to determine the number of times of receiving the log data acquisition request carrying the start offset, and when the number is less than or equal to a preset number, cause the above acquisition module to trigger and execute acquiring the target log data from the multiple packet log data included in the first compressed log file according to the start offset and the data size.

[0330] Further, the detection of meeting the condition for reporting the log file to the third device includes: receiving a log file list acquisition request sent by the third device; and / or the log file meets a set requirement; wherein, meeting the set requirement includes at least one of the following: reaching the reporting period, the number of log files reaching a set number, and the storage duration of the log file reaching a set duration.

[0331] For the specific implementation description of the functions of each module in the log reporting device provided in this embodiment, reference may be made to the relevant content of the method embodiment provided in this application in combination with Figure 6 the provided method embodiment.

[0332] Figure 15 FIG. shows a schematic structural diagram of a log reporting device provided in another embodiment of the present application. The device is deployed on a target second device, and the target second device is one of at least one second device; the at least one second device is a slave device that communicates with a first device in a master-slave manner. As shown in Figure 15, the log reporting device provided in this embodiment includes: a receiving module 71, a saving module 72, a establishing module 73, and a sending module 74. Among them, the receiving module 71 is used to receive the reporting status notification sent by the first device and the communication connection information between the first device and the third device; wherein, the reporting status notification is used to inform that the current log file reporting status is the file information to be reported status; the saving module 72 is used to save the current log file reporting status; the establishing module 73 is used to establish a communication connection with the third device according to the communication connection information; the sending module 74 is used to, after establishing a communication connection with the third device, send the file information of the second compressed log file in the target second device to the third device according to the saved current log file reporting status, so that the third device can perform the sub-packet collection operation of the second compressed log file on the target second device according to the received file information; wherein, the communication connection information is sent when the first device performs the master-slave switch with the target second device in the case that the device identifier of the target second device is included in the file name specified in the received file information acquisition request; the file information acquisition request is sent by the third device to the first device according to the received log file list; the log file list is generated by the first device according to the file name of the first compressed log file in the first device and the file names of the second compressed log files in the at least one second device and sent to the third device; after the target second device establishes a communication connection with the third device, the device role status of the target second device is switched from a slave device to a master device, and the third device disconnects the communication connection with the first device;

[0333] Further, the device provided in this embodiment further includes: a prohibiting module, which is used to prohibit the target second device from spontaneously performing a master-slave switch after establishing a communication connection with the third device.

[0334] Further, the above receiving module 71 is further configured to receive a log data acquisition request sent by the third device for the second compressed log file; wherein, the log data acquisition request carries the start offset, data size, and frame log bitmap of the target packet log data requested; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or all frame logs in the target packet log data need to be uploaded; the target packet log data is one packet log data among the multiple packet log data included in the second compressed log file; and the apparatus provided in this embodiment further includes: an acquisition module, configured to acquire the target packet log data from the multiple packet log data included in the second compressed log file according to the start offset and the data size; the above sending module 74 is further configured to, if the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted, determine the frame numbers of the frame logs that need to be retransmitted according to the frame log bitmap; selectively retransmit multiple frame logs in the target packet log data to the third device according to the frame numbers and the negotiated frame length; and the above sending module 74 is further configured to, if the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded, transmit multiple frame logs in the target packet log data to the third device frame by frame.

[0335] Further, the above receiving module 71 is further configured to, after receiving the completion notification of the collection of the second compressed log file sent by the third device, lift the prohibition on the target second device from spontaneously performing master-slave switching.

[0336] Further, the apparatus provided in this embodiment further includes: a compression module, configured to compress multiple log files in the target second device together to obtain the second compressed log file when receiving the preparation log file reporting notification sent by the first device; wherein, the file name of the second compressed log file carries the device identifier of the target second device; the above sending module is further configured to send the file name of the second compressed log file to the first device.

[0337] Further, the above acquisition module is further configured to acquire the logs generated by the application on the target second device; and the apparatus provided in this embodiment further includes: a processing module, configured to perform hash processing on the logs to obtain the hashed logs; a writing module, configured to write the hashed logs into the log file corresponding to the application.

[0338] For the specific implementation descriptions of the functions of each module in the log reporting apparatus provided in this embodiment, reference may be made to the relevant content of the method embodiment provided in this application in combination with Figure 9 the provided method embodiment.

[0339] Figure 16The figure shows a schematic structural diagram of a log reporting device provided by another embodiment of the present application. The device is deployed on a third device. As shown in Figure 16 , the log reporting device provided in this embodiment includes: a display module 81, a sending module 82, an establishing / disconnecting module 83, a receiving module 84, and an execution module 85. Among them, the display module 81 is used to display an interactive interface; the sending module 82 is used to send a log file list acquisition request to a first device selected by the user for log reporting in response to an operation triggered by the user through the interactive interface; and the sending module 82 is further used to send a file information acquisition request to the first device according to the log file list fed back by the first device; the establishing / disconnecting module 83 is used to establish a communication connection with the target second device in response to a communication connection request sent by the target second device, and disconnect the communication connection with the first device; the receiving module 84 is used to receive the file information of the second compressed log file in the target second device sent by the target second device; the execution module 85 is used to perform a sub-packet collection operation of the second compressed log file on the target second device according to the file information of the second compressed log file and the log file transmission parameters; wherein, the first device performs master-slave communication with at least one second device, and the log file list is generated by the first device according to the file names of the first compressed log files in the first device and the file names of the second compressed log files in the at least one second device; the target second device is one of the at least one second devices; the target second device sends a communication connection request to the third device according to the communication connection information between the first device and the third device received; the first device sends the communication connection information to the target second device when performing master-slave switching with the target second device when it is determined that the file name specified in the received file information acquisition request carries the device identifier of the target second device.

[0340] Further, the file information of the second compressed log file includes: the total file size, and the verification information, which is used for the third device to verify the collected second compressed log file; the log file transmission parameters include: the maximum transmission length, the frame length of the frame log, the transmission interval duration, and the retransmission support situation; the maximum transmission length is equal to the frame length multiplied by the maximum number of continuously transmissible frame logs.

[0341] Further, when the retransmission support condition is to support bitmap-based log retransmission, the above-mentioned execution module 85, when used to perform the sub-packet collection operation of the second compressed log file to the target second device according to the file information of the second compressed log file and the log file transmission parameters, is specifically used for: sending a log data acquisition request to the target second device according to the file information of the second compressed log file and the log file transmission parameters; wherein, the parameters carried in this request include: the starting offset, data size, and frame log bitmap of the target packet log data requested, and the frame log bitmap indicates that some frame logs in the target packet log data of this request need to be retransmitted or indicates that all frame logs in the target packet log data of this request need to be uploaded; the above-mentioned receiving module 84 is further used to receive the frame logs sent by the target second device in response to this request; and the device provided in this embodiment further includes: a determination module, used to determine the frame number of the received frame logs according to the information carried in the received frame logs; a setting module, used to set the value of the bit corresponding to the frame number of the received frame logs in the frame log bitmap corresponding to this request to the received value; the above-mentioned determination module is further used to, when it is time to send the next log data acquisition request, determine the parameters to be carried in the next request according to the frame log bitmap corresponding to this request until the collection of the second compressed log file is completed.

[0342] Further, when the above-mentioned determination module is used to determine the parameters to be carried in the next request according to the frame log bitmap corresponding to this request, it is specifically used for: determining whether there are lost frames in the target packet log data requested according to the frame log bitmap corresponding to this request; when there are lost frames, determining the starting offset, data size, and the corresponding frame log bitmap of the target packet log data of this request as the starting offset, data size, and frame log bitmap of the target packet log data to be carried in the next request respectively; when there are no lost frames, determining the sum of the starting offset and data size of the target packet log data of this request as the starting offset of the target packet log data to be carried in the next request; all the values corresponding to the bits in the frame log bitmap to be carried in the next request are not received values, the data size is the maximum transmission length, or the difference between the total file size of the second compressed log file and the size of all received packet log data.

[0343] Further, the above-mentioned time to send the next log data acquisition request includes: not receiving frame logs when the waiting duration exceeds the transmission interval duration; and / or the number of received frame logs reaches the maximum number of frames that can be continuously transmitted for a log data acquisition request.

[0344] For the specific implementation description of the functions of each module in the log reporting device provided in this embodiment, reference can be made to the relevant content of the method embodiment provided in this application in combination with Figure 10 the relevant content of the provided method embodiment.

[0345] Figure 17 The structural schematic diagram of a log reporting device provided by another embodiment of the present application is shown. The device is deployed on a first device. As shown in Figure 17 , the log reporting device provided in this embodiment includes: a receiving module 91, an obtaining module 92, and a determining and sending module 93. Among them, the receiving module 91 is configured to receive a log data acquisition request sent by a third device for a first compressed log file in the first device; wherein, the log data acquisition request carries the start offset, data size, and frame log bitmap of the target packet log data requested; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or indicates that all frame logs in the target packet log data need to be uploaded; the obtaining module 92 is configured to obtain the target packet log data from the multi-packet log data included in the first compressed log file according to the start offset and the data size; the determining and sending module 93 is configured to, if the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted, determine the frame numbers of the frame logs that need to be retransmitted according to the frame log bitmap; selectively retransmit multiple frame logs in the target packet log data to the third device according to the frame numbers and the negotiated frame length; and the determining and sending module 93 is further configured to, if the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded, send multiple frame logs in the target packet log data to the third device frame by frame.

[0346] Further, the above receiving module 91 is further configured to receive a negotiation request sent by the third device; wherein, the negotiation request carries log file transfer parameters. The above determining and sending module 93 is further configured to send the negotiation result of the log file transfer parameters to the third device, so that the third device sends a log data acquisition request to the first device for the first compressed log file according to the negotiated log file transfer parameters and the file information of the obtained first compressed log file; wherein, the log file transfer parameters include at least one of the following: maximum transfer length, frame length of frame logs, transfer interval duration, retransmission support situation; the maximum transfer length is equal to the frame length multiplied by the maximum number of consecutive frame logs that can be transferred for a single log data request; when the retransmission support situation is to support bitmap-based log retransmission, the log data acquisition request sent by the third device carries a frame log bitmap.

[0347] For the specific implementation description of the functions of each module in the log reporting device provided in this embodiment, reference may be made to the relevant content of the method embodiment provided in the present application in combination with Figure 11 the provided content.

[0348] Figure 18The figure shows a schematic structural diagram of a log reporting device provided by another embodiment of the present application. The device is deployed on a first device, and the first device has a communication connection established with a third device, and the third device has a log file collection function. As shown in Figure 18 , the log reporting device provided in this embodiment includes: an acquisition module 1001, a processing module 1002, a writing module 1003, a compression module 1004, and a sending module 1005. Among them, the acquisition module 1001 acquires the logs generated by the application on the first device; the processing module 1002 is used to perform hash processing on the logs generated by the application to obtain the hashed logs; the writing module 1003 is used to write the hashed logs into the log file corresponding to the application; the compression module 1004 is used to compress all the log files in the first device together to obtain a first compressed log file when it is detected that the condition for reporting the log file to the third device is met; the sending module 1005 is used to send the file information of the first compressed log file to the third device for the third device to perform the sub-packet collection operation of the first compressed log file on the first device according to the file information.

[0349] Furthermore, the above-mentioned first device is also in a master-slave communication connection with at least one second device, and the first device is the master device in the master-slave communication connection; and the above-mentioned sending module is also used to send notifications to the at least one second device respectively to notify that the log file is ready to be reported; the above-mentioned receiving module is also used to receive the file names of the second compressed log files sent by the at least one second device respectively; and, the device provided in this embodiment further includes: a generating module, which is used to generate a log file list according to the file name of the first compressed log file and the received file names of the second compressed log files; and the above-mentioned sending module is also used to send the log file list to the third device; wherein, the file name of the first compressed log file carries the device identifier of the first device; the second compressed log file is obtained by compressing all the log files in the corresponding second device in response to the notification; the file name of the second compressed log file carries the device identifier of the corresponding second device.

[0350] Further, when the sending module is used to send the file information of the first compressed log file to the third device, it is specifically configured to: in response to a file information acquisition request sent by the third device according to the log file list, determine the file name specified in the request; if the specified file name carries the device identifier of the first device, obtain the file information of the first compressed log file, and send the file information of the first compressed log file to the third device; wherein, the file information of the first compressed log file includes: the total file size, and the verification information, which is used for the third device to verify the collected first compressed log file.

[0351] For the specific implementation description of the functions of each module in the log reporting device provided in this embodiment, reference can be made to the relevant content of the method embodiment provided in this application in combination with Figure 12 the provided method embodiment.

[0352] This application also provides an electronic device, which is the first device, the second device, or the third device in the above system. As shown in Figure 19 or Figure 20 , the electronic device includes: a memory 1011, a processor 1012, and a communication module 1013.

[0353] Among them, the above-mentioned memory 1011 is used to store programs (computer programs), and can be configured to store various other data to support operations on the electronic device. Examples of these data include instructions for any application program or method for operating the electronic device, etc. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0354] The above-mentioned communication module 1013 is configured to facilitate communication between the device where the communication module is located and other devices in a wired or wireless manner. The device where the communication module is located can access a wireless network based on communication standards, such as Bluetooth, WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication module receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication module further includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0355] The processor 1012 is coupled to the memory 1011 and is configured to execute the computer program in the memory.

[0356] As shown in Figure 19 , when the electronic device is the first device 10 or the second device 20, the electronic device further includes: a service component 1014 containing a log service module; the service component 1014 communicates with a corresponding external device through the communication component; the log service module (referred to as the log service for short) is configured to perform management operations on the logs generated by the applications on the electronic device, and the management operations include at least one of the following: performing hash processing on the logs, writing the hashed logs into corresponding log files, and compressing all the log files in the electronic device together;

[0357] Wherein, when the electronic device is the first device, the processor 1012 controls the service component 1014 to execute the program stored in the memory, so that the electronic device implements the Figure 6 or Figure 11 or Figure 12 steps in the log reporting method provided by the embodiment of the present application shown; when the electronic device is the second device, the processor controls the service component to execute the program stored in the memory, so that the electronic device implements the Figure 9 steps in the log reporting method provided by the embodiment of the present application shown.

[0358] The above-mentioned first device or second device is often a thin device, such as a speaker, a headset, a microphone, etc.

[0359] Further, as Figure 19 shown, when the electronic device is the first device or the second device, the electronic device further includes: a power supply component 1016 and other components such as an audio module 1015. Figure 19 Only some components are schematically shown in Figure 19 , and it does not mean that the electronic device only includes the

[0360] As shown in Figure 20 , when the electronic device is the third device 30, the electronic device further includes a log collection application 1010 (such as the smart space application shown in Figure 20 ); wherein, the log collection application communicates with a corresponding external device through the communication component; the processor controls the log collection application to execute the program stored in the memory, so that the electronic device implements the Figure 10 steps in the log reporting method provided by the embodiment of the present application shown.

[0361] The above-mentioned third device is often a rich device. For example, the third device can be various electronic devices such as mobile phones, tablet computers, PDAs (Personal Digital Assistants), netbooks, desktop computers, virtual reality devices (AR / VR devices), in-vehicle computers, etc.

[0362] Furthermore, as Figure 20 shown, when the electronic device is the third device, the electronic device also includes other components such as a power supply component 1016 and an audio module 1015. Among them, the power supply component 1016 includes a charging management module, a power management module, a battery, etc.; in addition, the electronic device may further include: a motor, an indicator, a sensor module, a display screen, a camera, a button, an external interface, etc. Figure 20 Only some components of the electronic device are schematically shown, which does not mean that the electronic device only includes Figure 20 the components shown when it is the third device.

[0363] The above-mentioned motor can generate a vibration prompt. For example, it can be used for touch vibration feedback.

[0364] The above-mentioned indicator can be an indicator light, which is used to indicate the charging state, the change of battery power, and can also be used to indicate messages, notifications, etc.

[0365] The above-mentioned sensor module may include a pressure sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, etc. Among them,

[0366] The pressure sensor is used to sense the pressure signal and can convert the pressure signal into an electrical signal. For example, it can be a resistive pressure sensor, an inductive pressure sensor, a capacitive pressure sensor, etc.

[0367] The fingerprint sensor is used to collect fingerprints. The electronic device can use the collected fingerprint characteristics to achieve fingerprint unlocking, etc.

[0368] The temperature sensor is used to detect the temperature. In some embodiments, the electronic device uses the temperature detected by the temperature sensor to execute a temperature processing strategy. For example, when the temperature reported by the temperature sensor exceeds the threshold, the electronic device reduces the performance of the processor near the temperature sensor to reduce power consumption and implement thermal protection. In other embodiments, when the temperature is lower than another threshold, the electronic device heats the battery to avoid abnormal shutdown of the electronic device caused by low temperature. In other embodiments, when the temperature is lower than yet another threshold, the electronic device boosts the output voltage of the battery to avoid abnormal shutdown caused by low temperature. The touch sensor is also called a "touch control device".

[0369] The touch sensor is used to detect touch operations and transmit them to the processor to determine the type of touch event.

[0370] An ambient light sensor for sensing the ambient light brightness. The electronic device can adaptively adjust the display screen brightness, etc. according to the sensed ambient light brightness.

[0371] The above audio module 1015 is used to convert digital audio information into an analog audio signal for output, and is also used to convert an analog audio input into a digital audio signal. The audio module can also be used for encoding and decoding audio signals. In some embodiments, the audio module can be disposed in the processor, or some functional modules of the audio module can be disposed in the processor.

[0372] The above display screen is used to display images, videos, systems, or various application interfaces, etc. The display screen includes a display panel, and the display panel can adopt a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. In some embodiments, the electronic device can include one or N display screens 20, where N is a positive integer greater than 1.

[0373] The above camera is used to capture still images or videos.

[0374] The above buttons include a power-on button, a keyboard, etc. The buttons can be mechanical buttons or touch buttons. The electronic device can receive button inputs and generate key signal inputs related to the user settings and function controls of the electronic device.

[0375] The above memory is an internal memory and can be used to store computer-executable program code. The executable program code includes instructions. The memory can include a program storage area and a data storage area. Among them, the program storage area can store an operating system, application programs required for at least one function (such as a sound playback function, an image playback function, etc.). The data storage area can store data created during the use of the electronic device (such as audio data, a phone book, etc.). In addition, the memory can include a high-speed random access memory and can 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 executes various functional applications and data processing of the electronic device by running the instructions stored in the memory and / or the instructions stored in the memory disposed in the processor.

[0376] The above external interface can include a power interface, a USB interface, a headphone interface, etc.

[0377] The above charging management module is used to receive charging input from a charger. Among them, the charger can be a wireless charger or a wired charger. In some embodiments of wired charging, the charging management module can receive the charging input of the wired charger through an external power interface. In some embodiments of wireless charging, the charging management module can receive the wireless charging input through the wireless charging coil of the electronic device 100. While charging the battery, the charging management module can also supply power to the electronic device through the power management module.

[0378] The above power management module is used to connect the battery, the charging management module and the processor. The power management module receives the input from the battery and / or the charging management module and supplies power to the processor, the internal memory, the display screen, the camera, the communication module, etc. The power management module can also be used to monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage, impedance). In some other embodiments, the power management module can also be provided in the processor. In some other embodiments, the power management module and the charging management module can also be provided in the same device.

[0379] In addition, an embodiment of the present application further provides a computer-readable storage medium. A computer program is stored in the computer-readable storage medium, and when the computer program is executed, it can implement the steps in the above method embodiments.

[0380] Moreover, an embodiment of the present application further provides a computer program product. The computer program product includes a computer program or instruction, and when the computer program or instruction is executed by a processor, the processor can implement the steps in the above method embodiments provided by the present application.

[0381] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. Computer-usable storage media include, but are not limited to, disk memories, CD-ROMs, optical memories, etc.

[0382] This application is described with reference to the flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a means for implementing the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram.

[0383] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction means that implements the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram.

[0384] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram.

[0385] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0386] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of computer-readable media.

[0387] A computer-readable medium includes both permanent and non-permanent, removable and non-removable media and can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer-readable medium does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0388] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or apparatus comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or apparatus. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising the element.

[0389] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A log reporting method, characterized in that, Applicable to a first device, the first device being a master device for master-slave communication with at least one second device and also communicating with a third device having a log file collection function; the method includes: When it is detected that the condition for reporting the log file to the third device is satisfied, generate a log file list according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device; Send the log file list to the third device; In response to a file information acquisition request sent by the third device according to the log file list, determine the file name specified in the request; If the specified file name carries the device identifier of the target second device, perform a master-slave switch with the target second device, so that the target second device switches to be the master device to communicate with the third device, in order to send the file information of the second compressed log file in the target second device to the third device, for the third device to perform a sub-packet collection operation on the second compressed log file of the target second device according to the received file information; wherein, the target second device is one of the at least one second device.

2. The method according to claim 1, wherein Performing a master-slave switch with the target second device includes: Send the communication connection information between the first device and the third device to the target second device, so that the target second device establishes a communication connection with the third device according to the communication connection information, and after establishing the communication connection with the third device, prohibit the target second device from spontaneously performing a master-slave switch; Disconnect the communication connection with the third device.

3. The method according to claim 1, characterized in that When the specified file name carries the device identifier of the target second device, The method further includes: Send a reporting status notification to the target second device to inform the target second device that the current log file reporting status is the status of the file information of the second compressed log file to be reported.

4. The method according to any one of claims 1 to 3, characterized in that, Before generating a log file list according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device, the method further includes: Send notifications to the at least one second device respectively to notify the preparation for reporting log files; Compress multiple log files in the first device together to obtain the first compressed log file; the file name of the first compressed log file carries the device identifier of the first device; Receive the file names of the second compressed log files sent by the at least one second device respectively; wherein, the second compressed log file is obtained by the second device compressing multiple log files in the second device together in response to the notification; the file name of the second compressed log file carries the device identifier of the second device.

5. The method according to claim 4, wherein Further includes: Obtain the logs generated by the applications on the first device; Perform hash processing on the logs generated by the applications to obtain the hashed logs; Write the hashed logs into the log files corresponding to the applications.

6. The method according to claim 4, characterized in that Further includes: The first compressed log file is divided into multiple packets of log data so that the first compressed log file can be reported in packets to the third device subsequently; wherein, one packet of log data contains multiple frames of logs.

7. The method according to any one of claims 1 to 3, characterized in that It further includes: If the specified file name carries the device identifier of the first device, the file information of the first compressed log file is sent to the third device, so that the third device can perform the packet collection operation of the first compressed log file on the first device according to the file information of the first compressed log file and the log file transfer parameters negotiated with the first device; Wherein, the file information includes: total file size, check information; the check information is used for the third device to check the collected first compressed log file; The log file transfer parameters include at least one of the following: maximum transfer length, frame length of frame logs, transfer interval duration, retransmission support situation; the maximum transfer length is equal to the frame length multiplied by the maximum number of consecutive frame logs that can be transmitted for a single log data acquisition request.

8. The method according to claim 7, wherein The retransmission support situation is to support bitmap-based log retransmission; And The method further includes: Receiving a log data acquisition request sent by the third device for the first compressed log file; wherein, the log data acquisition request carries the start offset, data size and frame log bitmap of the requested target packet of log data; the frame log bitmap indicates that some frame logs in the target packet of log data need to be retransmitted or indicates that all frame logs in the target packet of log data need to be uploaded; the target packet of log data is one packet of log data among the multiple packets of log data included in the first compressed log file; Obtaining the target packet of log data from the multiple packets of log data included in the first compressed log file according to the start offset and the data size; If the frame log bitmap indicates that some frame logs in the target packet of log data need to be retransmitted, determining the frame numbers of the frame logs that need to be retransmitted according to the frame log bitmap; selectively retransmitting multiple frames of logs in the target packet of log data to the third device according to the frame numbers and the negotiated frame length; If the frame log bitmap indicates that all frame logs in the target packet of log data need to be uploaded, transmitting multiple frames of logs in the target packet of log data to the third device frame by frame.

9. The method according to claim 8, characterized in that, It further includes: Determining the number of times of receiving the log data acquisition request carrying the start offset; When the number of times is less than or equal to a preset number of times, triggering the step of obtaining the target log data from the multiple packets of log data included in the first compressed log file according to the start offset and the data size.

10. The method according to any one of claims 1 to 3, characterized in that, Detecting that the conditions for reporting the log file to the third device are met, including: Receiving a log file list acquisition request sent by the third device; and / or The log file meets the set requirements; wherein, meeting the set requirements includes at least one of the following: reaching the reporting period, the number of log files reaching the set number, the storage duration of the log file reaching the set duration.

11. A log reporting method, characterized in that, Applicable to the target second device, the target second device is one of at least one second device; The at least one second device is a slave device and communicates with the first device in a master-slave manner; the method includes: Receiving the reporting status notification sent by the first device and the communication connection information between the first device and the third device; wherein, the reporting status notification is used to inform that the current log file reporting status is the file information to be reported status; Saving the current log file reporting status; Establishing a communication connection with the third device according to the communication connection information; After establishing a communication connection with the third device, according to the saved current log file reporting status, sending the file information of the second compressed log file in the target second device to the third device, so that the third device performs the sub-packet collection operation of the second compressed log file on the target second device according to the received file information; Wherein, the communication connection information is sent when the first device performs a master-slave switch with the target second device when it is determined that the file name specified in the received file information acquisition request carries the device identifier of the target second device; the file information acquisition request is sent by the third device to the first device according to the received log file list; the log file list is generated by the first device according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device and sent to the third device; after the target second device establishes a communication connection with the third device, the device role status of the target second device is switched from a slave device to a master device, and the third device disconnects the communication connection with the first device.

12. The method according to claim 11, wherein It further includes: After establishing a communication connection with the third device, prohibiting the target second device from spontaneously performing a master-slave switch.

13. The method according to claim 11 or 12, characterized in that, It further includes: Receiving a log data acquisition request sent by the third device for the second compressed log file; wherein, the log data acquisition request carries the start offset, data size, and frame log bitmap of the requested target packet log data; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or all frame logs in the target packet log data need to be uploaded; the target packet log data is one packet of the multi-packet log data included in the second compressed log file; Obtaining the target packet log data from the multi-packet log data included in the second compressed log file according to the start offset and the data size; If the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted, determining the frame numbers of the frame logs to be retransmitted according to the frame log bitmap; selectively retransmitting the multi-frame logs in the target packet log data to the third device according to the frame numbers and the negotiated frame length; If the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded, sending the multi-frame logs in the target packet log data to the third device frame by frame.

14. The method according to claim 12, characterized in that, It further includes: After receiving the second compressed log file collection completion notification sent by the third device, lifting the prohibition on the target second device from spontaneously performing a master-slave switch.

15. The method according to claim 11 or 12, characterized in that It further includes: When receiving the notification for reporting the prepared log files sent by the first device, compress multiple log files in the target second device together to obtain the second compressed log file; wherein, the file name of the second compressed log file carries the device identifier of the target second device; Send the file name of the second compressed log file to the first device.

16. The method according to claim 11 or 12, characterized in that It further includes: Obtain the logs generated by the application on the target second device; Perform hash processing on the logs to obtain the hashed logs; Write the hashed logs into the log file corresponding to the application.

17. A log reporting method, characterized in that, Applicable to a third device, the method includes: Display an interactive interface; In response to an operation triggered by the user through the interactive interface, send a log file list acquisition request to the first device selected by the user for log reporting; According to the log file list fed back by the first device received, send a file information acquisition request to the first device; In response to a communication connection request sent by the target second device, establish a communication connection with the target second device and disconnect the communication connection with the first device; Receive the file information of the second compressed log file in the target second device sent by the target second device; According to the file information of the second compressed log file and the log file transmission parameters, perform a sub-packet collection operation of the second compressed log file on the target second device; Wherein, the first device is the master device for master-slave communication with at least one second device, and the log file list is generated by the first device according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device; the target second device is one of the at least one second device; the target second device sends a communication connection request to the third device according to the communication connection information between the first device and the third device received; the first device sends the communication connection information to the target second device when performing master-slave switching with the target second device upon determining that the file name specified in the received file information acquisition request carries the device identifier of the target second device.

18. The method according to claim 17, wherein The file information of the second compressed log file includes: total file size, verification information; the verification information is used for the third device to verify the collected second compressed log file; The log file transmission parameters include: maximum transmission length, frame length of frame logs, transmission interval duration, retransmission support situation; the maximum transmission length is equal to the frame length multiplied by the maximum number of consecutive frame logs that can be transmitted for one log data acquisition request.

19. The method according to claim 18, characterized in that When the retransmission support situation is to support bitmap-based log retransmission, According to the file information of the second compressed log file and the log file transmission parameters, performing the sub-packet collection operation of the second compressed log file on the target second device includes: Send a log data acquisition request to the target second device according to the file information of the second compressed log file and the log file transfer parameters; wherein, the parameters carried in this request include: the start offset, data size, and frame log bitmap of the target packet log data requested, and the frame log bitmap indicates that some frame logs in the target packet log data requested this time need to be retransmitted or indicates that all frame logs in the target packet log data requested this time need to be uploaded; Receive the frame logs sent by the target second device in response to this request; Determine the frame number of the received frame logs according to the information carried in the received frame logs; Set the value of the bit corresponding to the frame number of the received frame logs in the frame log bitmap corresponding to this request to the received value; When it is time to send the next log data acquisition request, determine the parameters to be carried in the next request according to the frame log bitmap corresponding to this request until the collection of the second compressed log file is completed.

20. The method according to claim 19, wherein Determine the parameters to be carried in the next request according to the frame log bitmap corresponding to this request, including: Determine whether there are missing frames in the target packet log data requested this time according to the frame log bitmap corresponding to this request; When there are missing frames, determine the start offset, data size, and frame log bitmap of the target packet log data to be carried in the next request as the start offset, data size, and frame log bitmap of the target packet log data requested this time, respectively; When there are no missing frames, determine the sum of the start offset and data size of the target packet log data requested this time as the start offset of the target packet log data to be carried in the next request; the values corresponding to all bits in the frame log bitmap to be carried in the next request are all unreceived values, the data size is the maximum transmission length, or the difference between the total file size of the second compressed log file and the size of all received packet log data.

21. The method according to claim 19, wherein The time to reach the point of sending the next log data acquisition request includes: Not receiving frame logs when the waiting duration exceeds the transmission interval duration; and / or The number of received frame logs reaches the maximum number of frames that can be continuously transmitted for a log data acquisition request.

22. A log reporting method, characterized in that, Applicable to the first device, the method includes: Receive a log data acquisition request sent by a third device for the first compressed log file in the first device; wherein, the log data acquisition request carries the start offset, data size, and frame log bitmap of the target packet log data requested; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or indicates that all frame logs in the target packet log data need to be uploaded; Obtain the target packet log data from the multiple packet log data included in the first compressed log file according to the start offset and the data size; If the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted, determine the frame numbers of the frame logs to be retransmitted according to the frame log bitmap; selectively retransmit multiple frame logs in the target packet log data to the third device according to the frame numbers and the negotiated frame length; If the frame log bit map indicates that all frame logs in the target packet log data need to be uploaded, the multiple frame logs in the target packet log data are sent frame by frame to the third device.

23. The method according to claim 22, wherein It further includes: Receiving a negotiation request sent by the third device; wherein, the negotiation request carries log file transfer parameters; Sending the negotiation result of the log file transfer parameters to the third device, so that the third device sends a log data acquisition request to the first device for the first compressed log file according to the negotiated log file transfer parameters and the file information of the first compressed log file obtained; Wherein, the log file transfer parameters include at least one of the following: maximum transfer length, frame length of frame logs, transfer interval duration, retransmission support situation; the maximum transfer length is equal to the frame length multiplied by the maximum number of consecutive frame logs that can be transferred for one log data request; when the retransmission support situation is to support log retransmission based on a bitmap, the log data acquisition request sent by the third device carries a frame log bitmap.

24. A log reporting method, characterized in that, Applicable to a first device, the first device is communicatively connected to a third device, and the third device has a log file collection function; the method includes: Obtaining the logs generated by the application on the first device; Performing a hash process on the logs generated by the application to obtain the hashed logs; Writing the hashed logs into the log file corresponding to the application; When it is detected that the condition for reporting the log file to the third device is satisfied, compressing all the log files in the first device together to obtain a first compressed log file; Sending the file information of the first compressed log file to the third device for the third device to perform a sub-packet collection operation on the first compressed log file of the first device according to the file information.

25. The method according to claim 24, wherein The first device is also communicatively connected to at least one second device in a master-slave relationship, and the first device is the master device in the master-slave communication connection; And, the method further includes: Sending notifications to the at least one second device respectively to notify the preparation for reporting log files; Receiving the file names of the second compressed log files sent by the at least one second device respectively; Generating a log file list according to the file name of the first compressed log file and the received file names of the second compressed log files; Sending the log file list to the third device; Wherein, the file name of the first compressed log file carries the device identifier of the first device; the second compressed log file is obtained by compressing all the log files in the corresponding second device in response to the notification, and the file name of the second compressed log file carries the device identifier of the corresponding second device.

26. The method according to claim 25, characterized in that, Sending the file information of the first compressed log file to the third device includes: Responding to the file information acquisition request sent by the third device according to the log file list, and determining the file name specified by the request; If the device identifier of the first device is included in the specified file name, obtain the file information of the first compressed log file, and send the file information of the first compressed log file to the third device; Wherein, the file information of the first compressed log file includes: total file size, check information; the check information is used for the third device to check the collected first compressed log file.

27. A log reporting system, characterized in that, Including: A third device with a log file collection function; At least one second device; A first device, communicatively connected to the third device and master-slave communicatively connected to the at least one second device. In the master-slave communication connection, the first device is the master device. When it detects that the condition for reporting the log file to the third device is met, it generates a log file list according to the file name of the first compressed log file in the first device and the file name of the second compressed log file in the at least one second device; and sends the log file list to the third device; The third device is configured to take out a file name from the log file list, generate a file information acquisition request according to the taken-out file name, and send the file information acquisition request to the first device; The first device is further configured to, in response to the file information acquisition request, determine the file name specified in the request; if the device identifier of the target second device is included in the specified file name, perform a master-slave switch with the target second device, so that the target second device is switched to be the master device to communicate with the third device, in order to send the file information of the second compressed log file in the target second device to the third device, for the third device to perform the sub-packet collection operation of the second compressed log file on the target second device according to the received file information; wherein, the target second device is one of the at least one second device.

28. A log reporting system, characterized in that, Including: A third device with a log file collection function; A first device, communicatively connected to the third device, for receiving a log data acquisition request sent by the third device for the first compressed log file in the first device; wherein, the log data acquisition request carries the start offset, data size and frame log bitmap of the target packet log data requested; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or indicates that all frame logs in the target packet log data need to be uploaded; obtain the target packet log data from the multi-packet log data included in the first compressed log file according to the start offset and the data size; if the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted, determine the frame numbers of the frame logs to be retransmitted according to the frame log bitmap; selectively retransmit the multi-frame logs in the target packet log data to the third device according to the frame numbers and the negotiated frame length; if the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded, send the multi-frame logs in the target packet log data to the third device frame by frame.

29. An electronic device, characterized in that, The electronic device is a first device, a second device, or a third device; the electronic device includes: a memory, a processor, and a communication component; the memory is used for storing programs; the processor is coupled to the memory; When the electronic device is a first device or a second device, the electronic device further includes: a service component containing a log service module; the service component communicates with a corresponding external device through the communication component; the log service module is used for managing the logs generated by applications on the electronic device, and the management includes at least one of the following: performing hash processing on the logs, writing the hashed logs into corresponding log files, and compressing all the log files in the electronic device together; Wherein, when the electronic device is a first device, the processor controls the service component to execute the program stored in the memory, so that the electronic device implements the steps in the log reporting method described in any one of claims 1 to 10 above, or implements the steps in the log reporting method described in any one of claims 22 or 23 above, or implements the steps in the log reporting method described in any one of claims 24 to 26 above; when the electronic device is a second device, the processor controls the service component to execute the program stored in the memory, so that the electronic device implements the steps in the log reporting method described in any one of claims 11 to 16 above; When the electronic device is a third device, the electronic device further includes a log collection application; the log collection application communicates with a corresponding external device through the communication component; the processor controls the log collection application to execute the program stored in the memory, so that the electronic device implements the steps in the log reporting method described in any one of claims 17 to 21 above.

Images