Log reporting method, system and electronic device

Abstract

The application provides a log reporting method and system and an electronic device. In the application, a first device is a master device, at least one second device is in master-slave communication with the first device, and a third device having a log file collection function is in communication with the first device. When the first device determines that the third device requests file information of a second compressed log file in a target second device (one of the at least one second device), the first device performs master-slave switching, so that the target second device switches to become a master device and communicates with the third device. After the target second device communicates with the third device, the target second device sends the file information of the second compressed log file to the third device, and the third device performs second compressed log file reporting interaction with the target second device according to the received file information. The application introduces master-slave switching, so that the slave device can directly report the log file in the slave device to the third device without going through the original master device, which can effectively shorten the log reporting process of the slave device.

Description

Technical Field

[0001] This application relates to the field of data transmission technology, and in particular to a log reporting method, system, and electronic device. Background Technology

[0002] With the widespread adoption of rich devices such as smartphones, various other products that communicate with rich devices, such as thin devices like headphones and watches, are also emerging in large numbers. To provide users with high-quality product services, thin devices generally have log reporting capabilities. The log reporting process is as follows: When problems such as lag occur during the use of a thin device, the user can operate the rich device to trigger a problem feedback mechanism for the thin device. In response to the triggered problem feedback, the rich device will simultaneously request the thin device to report logs. After the rich device connects to the network, it will package the log files reported by the thin device and the log files of the rich device together and report them to the server. This allows the developers of the thin device to view and analyze the problem logs through the corresponding website to respond to and resolve the user's reported problems.

[0003] However, in the above log reporting process, in scenarios involving thin devices including master-slave devices, the log files of the slave device need to be obtained from the master device and reported to the rich device. Compared with the log reporting of the master device, the log reporting process of the slave device is more complex and takes too long. In addition, the existing log reporting of thin devices also suffers from problems such as excessively large log files, slow reporting speed, and packet loss during log reporting. Summary of the Invention

[0004] In view of the above problems, this application provides a log reporting method, system, and electronic device to simplify the log reporting process for slave devices, and further to reduce the log reporting size, improve the log reporting speed, and reduce the log packet loss rate. Therefore,

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

[0006] When the conditions for reporting log files to a third device are met, a log file list is generated based on 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] Send the log file list to the third device;

[0008] In response to the file information retrieval request sent by the third device based on the log file list, the file name specified in the request is determined;

[0009] If the specified filename contains the device identifier of the target second device, a master-slave switch is performed with the target second device, so that the target second device becomes the master device and communicates with the third device to 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 a 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 a second embodiment of this application, a log reporting method is also provided, applicable to a target second device, wherein the target second device is one of at least one second device; the at least one second device is a slave device that performs master-slave communication with a first device. The log reporting method includes:

[0011] The system receives a reporting status notification from the first device and communication connection information between the first device and the third device; wherein the reporting status notification is used to inform the user that the current log file reporting status is "file information pending reporting".

[0012] Save the current log file reporting status;

[0013] A communication connection is established with the third device based on the communication connection information;

[0014] After establishing a communication connection with the third device, the file information of the second compressed log file in the target second device is sent to the third device according to the saved current log file reporting status, so that the third device can perform the 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 by the first device when it performs a master-slave switch with the target second device after determining 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 based on the received log file list; the log file list is generated by the first device based on the file name of the first compressed log file in the first device and the file name of the second compressed log file in 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 slave device to master device, and the third device disconnects the communication connection with the first device.

[0016] In a third embodiment of this application, a log reporting method is also provided, applicable to a third device. The log reporting method includes:

[0017] Display the interactive interface;

[0018] In response to an operation triggered by the user through the interactive interface, a request to obtain a list of log files is sent to the first device selected by the user that needs to report logs.

[0019] Based on the log file list received from the first device, a file information retrieval request is sent to the first device;

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

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

[0022] Based on the file information and log file transmission parameters of the second compressed log file, perform a packet collection operation on the target second device for the second compressed log file;

[0023] Wherein, the first device is a master device that performs master-slave communication with at least one second device; the log file list is generated by the first device based on the filenames of the first compressed log files in the first device and the filenames 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 device; the target second device sends a communication connection request to the third device based on the communication connection information sent by the first device; the first device sends the communication connection information to the target second device when it determines that the filename specified in the received file information retrieval request contains the device identifier of the target second device, and performs a master-slave switch with the target second device.

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

[0025] The system receives 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 starting offset, data size, and frame log bitmap of the target packet log data; the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted or that all frame logs in the target packet log data need to be uploaded.

[0026] Based on the starting offset and the data size, the target packet log data is obtained from the multi-packet log data included in the first compressed log file;

[0027] If the frame log bitmap represents a portion of the frame logs in the target packet log data that need to be retransmitted, then the frame number of the frame logs that need to be retransmitted is determined according to the frame log bitmap; based on the frame number and the negotiated frame length, multiple frames of logs in the target packet log data are selectively retransmitted to the third device.

[0028] If the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded, then the multiple frame logs in the target packet log data are sent to the third device frame by frame.

[0029] In a fifth embodiment of this application, a log reporting method is also provided, applicable to a first device, wherein the first device and a third device have a communication connection, and the third device has a log file collection function. The log reporting method includes:

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

[0031] The logs generated by the application are hashed to obtain the hashed logs.

[0032] Write the hashed log to the log file corresponding to the application.

[0033] When the conditions for reporting log files to the third device are met, all log files in the first device are compressed together to obtain a first compressed log file;

[0034] The file information of the first compressed log file is sent to the third device, so that the third device can perform a packet collection operation of the first compressed log file on the first device according to the file information.

[0035] In the sixth embodiment of this application, a log reporting system is also provided, the system comprising:

[0036] The third device has log file collection capabilities;

[0037] At least one second device;

[0038] A first device is communicatively connected to the third device and in a master-slave communication connection with at least one second device. In the master-slave communication connection, the first device is the master device, which is used to generate a log file list based on the filename of the first compressed log file in the first device and the filename of the second compressed log file in the at least one second device when it detects that the conditions for reporting log files to the third device are met; and to send the log file list to the third device.

[0039] The third device is configured to retrieve a filename from the log file list, generate a file information retrieval request based on the retrieved filename, and send the file information retrieval 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 contains 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 become 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, so that the third device can perform a 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 this application, a log reporting system is also provided, the system comprising:

[0042] The third device has log file collection capabilities;

[0043] A first device, communicatively connected to the third device, is configured to receive a log data acquisition request sent by the third device for a first compressed log file in the first device. The log data acquisition request carries the starting offset, data size, and frame log bitmap of the requested target packet log data. The frame log bitmap indicates whether some frame logs in the target packet log data need to be retransmitted or whether all frame logs in the target packet log data need to be uploaded. Based on the starting offset and the data size, the target packet log data is acquired from the multi-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, the frame number of the frame logs to be retransmitted is determined based on the frame log bitmap. Based on the frame number and the negotiated frame length, multiple frame logs in the target packet log data are selectively retransmitted to the third device. If the frame log bitmap 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.

[0044] In eight embodiments of this application, an electronic device is also provided, which 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 to store a program; the processor is coupled to the memory.

[0045] 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 to manage logs generated by applications on the electronic device, and the management includes at least one of the following: hashing the logs, writing the hashed logs into the corresponding log files, and compressing all log files in the electronic device together;

[0046] 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 provided in the first, fourth, or fifth embodiment of this application; 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 provided in the second embodiment of this application.

[0047] 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 provided in the third embodiment of this application.

[0048] The technical solutions provided in the embodiments of this application involve a first device as a master device communicating with at least one second device and also communicating with a third device that has log file collection capabilities. When the first device determines that the third device requests file information of a second compressed log file from a target second device (one of the at least one second device), it performs a master-slave switch operation, causing the target second device to switch to master mode and communicate with the third device. After communicating with the third device, the target second device sends the file information of the second compressed log file to the third device, and the third device interacts with the target second device to report the second compressed log file based on the received file information. This solution introduces a master-slave switch before the log file is reported by the slave device, allowing the slave device to directly report its log files to the third device without going through the original master device. This effectively reduces the log reporting process for the slave device, thereby reducing the time required for log reporting and improving log reporting efficiency. Furthermore, the first device hashes the logs generated by its applications before writing them to the corresponding log files. When it detects that a log file needs to be reported to the third device, it compresses all log files in the first device into a single compressed log file (the first compressed log file). Upon determining that the third device requests file information from the first compressed log file, it sends the file information of the first compressed log file to the third device. The third device then interacts with the first device to report the first compressed log file based on the received file information (packet collection). This solution, by introducing log hashing and compression, significantly reduces the log data size, facilitating subsequent reductions in log reporting time and improving log reporting efficiency. Furthermore, during the log file reporting interaction (packet collection) between the third device and the first device based on the file information of the first compressed log file received from the first device, the log data acquisition request sent by the third device to the first device for the first compressed log file will carry the starting offset, data size, and frame log bitmap of the requested target packet log data. The frame log bitmap indicates whether some frame logs in the target packet log data need to be retransmitted or whether 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, according to the request... The first device determines the starting offset and data size, and obtains the target packet log data from the multi-packet log data included in the first compressed log file. 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 number of the frame logs that need to be retransmitted according to the frame log bitmap, and selectively resend multiple frame logs in the target packet log data to the third device according to the frame number and the negotiated frame length. If the frame log bitmap carried in the request indicates that all frame logs in the target packet log data are uploaded, the first device will send multiple frame logs in the target packet log data to the third device frame by frame.As can be seen, this solution also introduces a log selective retransmission mechanism based on bitmaps, which can quickly retransmit lost frame logs. Attached Figure Description

[0049] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0050] Figure 1a A schematic diagram illustrating the principle of existing Bluetooth device log reporting, provided for an exemplary embodiment of this application;

[0051] Figure 1b A schematic diagram illustrating the principle of viewing logs via a web client, provided for an exemplary embodiment of this application;

[0052] Figure 2 A schematic diagram illustrating the principle of log reporting in an existing master-slave device, provided for an exemplary embodiment of this application;

[0053] Figure 3 A schematic diagram illustrating the principle of frame-by-frame reporting of existing log files, provided for an exemplary embodiment of this application;

[0054] Figure 4a , Figure 4b as well as Figure 5 This is a schematic diagram of the structure of the log reporting system provided in the embodiments of this application;

[0055] Figure 6 A flowchart illustrating a log reporting method provided for an exemplary embodiment of this application;

[0056] Figure 7 A schematic diagram illustrating the principle of problem feedback provided for an exemplary embodiment of this application;

[0057] Figure 8 A schematic diagram illustrating the principle of log file packet reporting provided for an exemplary embodiment of this application;

[0058] Figures 9 to 12 A flowchart illustrating the log reporting method provided in this application embodiment;

[0059] picture Figure 13a and Figure 13b A schematic diagram of the log reporting sequence flow provided for this application;

[0060] Figures 14 to 18 This is a schematic diagram of the structure of the log reporting device provided in the embodiments of this application;

[0061] Figure 19 and Figure 20This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0062] With the development and widespread adoption of rich devices such as smartphones and tablets, various other products that communicate with rich devices, such as thin devices like headphones, watches, and fitness trackers, are also emerging in large numbers. Taking Bluetooth thin devices (thin devices that communicate based on the Bluetooth protocol) as an example, Bluetooth thin devices often experience problems such as lag, noise, or intermittent connection during use. In order to analyze Bluetooth thin device malfunctions and provide users with rapid response and troubleshooting services, as well as to facilitate data support for subsequent product iterations and updates, and ultimately provide users with higher quality products, the product needs to have log file reporting capabilities.

[0063] A log file is a record of a completed process by a device system or its applications for future reference. Currently, for log file reporting in Bluetooth thin devices, corresponding service components (WearSDKs) providing logging services are often developed. These service components offer external interfaces that can be integrated into products as needed. After integrating these service components, Bluetooth thin devices gain log file reporting capabilities. For details, please refer to [link to relevant documentation]. Figure 1a As shown, the log reporting process is as follows: After the Bluetooth thin device integrates WearSDK, logs generated by business services within WearSDK and applications on the device will be saved to the corresponding log files on the device by calling the corresponding interfaces through WearSDK. When a fault 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. The Bluetooth rich device responds to the triggered problem feedback by synchronously requesting the Bluetooth thin device to report logs. After the Bluetooth rich device connects to the network, it packages the log files reported by the Bluetooth thin device and the log files of the Bluetooth rich device together and reports them to the server on the network side for storage in the server's database. Developers can enter log search conditions through the website page (log viewing page P) provided by the web client, such as the log ID (e.g., the ID of the Bluetooth rich device (or the log collection application installed on it, such as the smart space application)), system version, log collection application version, approximate time of the problem occurrence, etc., and then click the "Query" control. The web client responds to this query operation and will provide the developers with the device logs that match the search conditions through the website page, such as... Figure 1b The device logs are displayed on the log viewing page P shown; furthermore, R&D personnel can trigger the "copy and open device log download link" operation on the corresponding logs to view and analyze the device logs, thereby responding to and resolving user feedback issues.

[0064] The existing Bluetooth thin device log file reporting process described above has the following problems:

[0065] 1. In scenarios where Bluetooth thin devices act as master and slave devices (including a master device and a slave device communicating with each other, and the master device also communicating with rich devices), it is necessary to obtain the slave device's log file through interaction between the master and slave devices. Furthermore, the slave device's log file is then reported to the Bluetooth rich device via the master device. For details, see [link to relevant documentation]. Figure 2 The diagram illustrates the log file reporting process for master and slave devices. The master device's log file reporting process includes four steps (1-2-3-4), while the slave device's log file reporting process, such as slave device 1, includes seven steps (1-2-3-3.1-3.2-3.3-3.4). Clearly, the slave device's log file reporting process is significantly longer than the master device's, resulting in longer reporting times and slower speeds for the slave device.

[0066] 2. Bluetooth thin devices do not perform any processing on the log files, but directly report the raw log files, resulting in a large final reported log file. This leads to slow and time-consuming log file reporting and low reporting efficiency.

[0067] 3. Packet loss issue. During log file reporting, due to the need to balance log reporting efficiency with the size and frequency of the underlying transmission buffer in Bluetooth thin devices, packet loss often occurs as a compromise. Furthermore, see [link to relevant documentation]. Figure 3 As shown, in the existing log file reporting process, the Bluetooth thin device divides the log file into multiple frames of log data. The log collection application on the Bluetooth rich device makes only one request to the Bluetooth thin device regarding the log file. In response to the request, the Bluetooth thin device sequentially reports the multiple frames of log data from the log file to the log collection application on the Bluetooth rich device. Because this entire reporting process does not respond to the log collection application's reply (and the log collection application does not reply), the Bluetooth thin device cannot know which frames are lost during the upload process, resulting in frame loss issues. This can lead to the loss of critical log information, affecting the efficiency and accuracy of analyzing user feedback issues.

[0068] To address the aforementioned issues, the basic design concept for log reporting in this application is as follows: For master-slave device log reporting scenarios, a master-slave role switch is introduced before the slave device reports its log files; in addition, before the thin device performs log reporting, the thin device hashes the generated logs, writes the hashed logs to the corresponding log files, and compresses all log files in the device into a single compressed log file for reporting; furthermore, during the log file reporting process, a selective retransmission mechanism based on a bitmap is introduced. Based on the bit information recorded in the bitmap, it is possible to determine which log data frames were lost during transmission for a single request, thus enabling the retransmission of lost log data frames in the next request to the rich device (specifically, the log collection application on the rich device).

[0069] Based on the above design concept, this application provides a log reporting method, system, and electronic device.

[0070] A detailed description of rich and thin devices will be provided below.

[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 and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0072] In the embodiments of this application, in order to clearly describe the technical solutions of the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. 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 order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0073] It should be noted that the words "exemplary" or "for example" in this application are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner. In addition, "at least one" in this application means one or more, and "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural, etc. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plural item. For example, at least one of a, b, and c can be represented as: a, b, c, a, b, and c, a and b, a and c, b and c.

[0074] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0075] The various method embodiments provided in this application can be implemented on the hardware corresponding to the log reporting system described below. Specifically,

[0076] In one specific implementation, see 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. The first device 10 and at least one second device 20 are connected via a master-slave communication module, with the first device 10 being the master and the second device 20 being the slave. Furthermore, the first device is also connected to the third device 30 via a communication module. The third device has a log file collection function. In specific implementations, the third device has an application with log collection capabilities (referred to as a log collection application in this context, such as a smart space application) installed on it, and the third device uses this log collection application to collect log files.

[0077] The first device 10 is configured to, when detecting that the conditions for reporting log files to the third device are met, generate a log file list based on the filename of the first compressed log file in the first device and the filename of the second compressed log file in the at least one second device; and send the log file list to the third device 30.

[0078] The third device 30 is used to retrieve a filename from the log file list, generate a file information retrieval request based on the retrieved filename, and send the file information retrieval 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 contains 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 become 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, so that the third device can perform a 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 aforementioned first device 10 and second device 20 are often referred to as thin devices. A thin device refers to a resource-constrained device, which may be an electronic device with storage space less than or equal to a first threshold, and / or processing performance less than or equal to a second threshold, and / or providing relatively simple functions. Generally, electronic devices with limited memory and storage space can be called thin devices. In specific implementations, thin devices (the first device and the second device) may include, but are not limited to, wireless Bluetooth headsets (hereinafter referred to as Bluetooth headsets), smart wearable devices such as wristbands and watches, smart speakers, wireless Bluetooth microphones, wireless Bluetooth keyboards and mice, etc. In addition to communication components, thin devices (the first device and the second device) also integrate other components, such as service components (WearSDK). WearSDK provides a logging service; in other words, WearSDK includes a logging service module (hereinafter referred to as the logging service), which can manage the logs generated by the device, including but not limited to hashing the logs, writing the hashed logs to the corresponding log files, and compressing the log files. Through the service component, thin devices can report relevant log files to rich devices (third devices). The specific implementation of log file reporting is detailed in the method examples provided below.

[0081] The aforementioned third device is a rich device. A rich device (or fat device) refers to a device with abundant resources. A resource-rich device can refer to an electronic device with storage space exceeding a first threshold, and / or processing performance exceeding a second threshold, and / or providing a variety of functions. Generally, electronic devices with ample memory and storage space can be called rich devices. In specific implementations, a rich device (third device) can be, but is not limited to, a mobile phone, tablet, laptop, etc.

[0082] When the first device 10, the second device 20 and the third device 30 establish corresponding communication connections, the communication modules used can be wireless communication modules, such as Bluetooth modules, Wi-Fi modules, Zigbee (self-bee technology) and other short-range communication components. Figure 4b The example shown illustrates a scenario where a Bluetooth module is used as the communication module. Figure 4b In the illustrated scenario, the first device 10 and the second device 20 can be referred to as Bluetooth thin devices, and the third device 30 can be referred to as Bluetooth rich devices.

[0083] The above Figure 4a and Figure 4b This diagram illustrates the structure of a log reporting system that includes master and slave devices. Of course, a log reporting system can also exist without master and slave devices; therefore:

[0084] In another specific feasible technical solution, see [link to relevant documentation] Figure 5 The log reporting system includes: a third device 30 and a first device 10; wherein.

[0085] The third device 30 has a log file collection function.

[0086] A first device, communicatively connected to the third device, is configured to receive a log data acquisition request sent by the third device for a first compressed log file in the first device. The log data acquisition request carries the starting offset, data size, and frame log bitmap of the requested target packet log data. The frame log bitmap indicates whether a portion of the frame logs in the target packet log data needs to be retransmitted or whether all the frame logs in the target packet log data need to be uploaded. Based on the starting offset, the target packet log data is acquired from the multi-packet log data included in the first compressed log file. If the frame log bitmap indicates that a portion of the frame logs in the target packet log data needs to be retransmitted, the frame number of the frame logs to be retransmitted is determined based on the frame log bitmap. Based on the frame number and the negotiated frame length, multiple frame logs in the target packet log data are selectively retransmitted to the third device. If the frame log bitmap indicates that all the 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.

[0087] For details regarding the communication connection method between the first and third devices, as well as their specific forms, please refer to the relevant content above; further details will not be provided here. Figure 5 Figure (b) shown on the left illustrates an example of a Bluetooth communication connection between the first device (Bluetooth thin device) and the third device (Bluetooth rich device).

[0088] The specific details of the functions of the first device, second device, third device, and other hardware in the log reporting systems described above will be elaborated and explained in detail in the following method embodiments.

[0089] Figure 6 This diagram illustrates a flowchart of a log reporting method according to an embodiment of this application. The execution entity for all steps in the method described in this embodiment can be the first device in the aforementioned system. More specifically, the steps in the method can be executed by a service component (WearSDK) in the first device. The first device is a master device that performs master-slave communication with at least one second device. The first device also communicates with a third device that has log file collection capabilities. For a description of the first device, second device, third device, and their communication methods, please refer to relevant content in other embodiments of this application.

[0090] See also Figure 6 The log reporting method provided in this embodiment includes the following steps:

[0091] 101. When the condition for reporting log files to a third device is met, a log file list is generated based on 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 retrieval request sent by the third device based on the log file list, determine the file name specified in the request;

[0094] 104. If the specified filename contains the device identifier of the target second device, perform a master-slave switch with the target second device, so that the target second device becomes the master device and communicates with the third device to 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 a 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.

[0095] In point 101 above, the timing of log file reporting can be either passive or active. Passive reporting refers to being triggered by a third device, while active reporting refers to being actively triggered by the first device. Reaching the log file reporting timing confirms that the conditions for reporting the log file to the third device are met.

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

[0097] ① Upon receiving the log file list retrieval request sent by the third device, determine that the conditions for reporting log files to the third device are met; and / or

[0098] ② When the log files meet the set requirements, it is determined that the conditions for reporting the log files to the third device are met; among them, meeting the set requirements includes at least one of the following: reaching the reporting cycle, the number of log files reaching the set number, and the log file storage time reaching the set duration.

[0099] In ① above, the request to retrieve the log file list may be sent by the third device based on the user-triggered problem feedback operation.

[0100] For example, if the first and / or second devices experience lag, noise, or other abnormalities during use, the user can trigger an error response by operating the log collection application installed on the third device and clicking "confirm." In response to the user's action, the log collection application will send a log file list retrieval request to the first device, which is communicatively connected to the third device, through the third device. More specifically, see... Figure 7 and combined Figure 5Taking the log collection application on the third device 30 as an example, the smart space application establishes a transmission channel (such as the UUID Bluetooth service channel of XXXX) between the communication module on the third device and the communication module on the first device and the service component (WearSDK) on the first device for log reporting interaction. Users can enter the "Help and Customer Service" page by operating the "Help and Customer Service" function on the smart space application page. This page provides a "Problem Feedback" entry. Clicking the "Problem Feedback" entry will take you to the problem feedback page. On the problem feedback page, you can enter the corresponding problem feedback information, such as selecting the device that needs to report the problem (such as selecting device 1 (the first device)), filling in the description of the device problem (the problem that occurred on the device), the probability of occurrence, time, and other information. After clicking the "Submit" control, the smart space application will trigger the process of collecting the corresponding device-side log files. In practice, in response to the above submission operation, the smart space application first generates a log file list retrieval request based on the user's input feedback information. Then, based on the corresponding internal proprietary protocol (such as the MBB protocol), the log file list retrieval request information is encapsulated and sent to the user-selected first device via the communication module of the third device and the transmission channel between the third device and the first device. After receiving the log file list request information (as a binary byte stream), the first device transmits the log file list retrieval request information to the WearSDK on the first device through its communication module and the external interface provided by WearSDK on the first device. The WearSDK on the first device parses the received log file list request information using internal proprietary protocols such as the MBB protocol to identify the specific service type (log service) and request type (log file list request). Thus, when the request type is determined to be a log file list request, the conditions for reporting log files to the third device are met.

[0101] The reporting cycle, set quantity, and set duration mentioned in ② above can be flexibly set according to actual conditions and are not limited here. The first device can automatically trigger 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 a log file list retrieval request as mentioned in ① above.

[0102] In this embodiment of the application, preferably, the condition for reporting the log file to the third device is determined by the method described in ① above.

[0103] After the conditions for reporting log files to the third device are met, the first and second devices will each perform a compression operation on multiple log files within themselves to obtain corresponding compressed log files. The purpose of this compression operation is to reduce the log file size, thereby shortening the time required for log file reporting and improving reporting efficiency during subsequent reporting processes. Specifically, the second device triggers the log file compression operation based on a log file list retrieval request synchronized from the first device, and after compression, returns the filename of the resulting second compressed log file to the first device for use in generating the log file list. Based on this, before triggering the execution of step 101, "generating a log file list based on the filename of the first compressed log file in the first device and the filename of the second compressed log file in at least one second device," the method provided in this embodiment may further include the following steps:

[0104] 100a. Send a notification to each of the at least one second device to notify it of the read / write log file preparation.

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

[0106] 100c. Receive the filenames 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 filename of the second compressed log file contains the device identifier of the second device.

[0107] In the above 100a, after the first device determines that its WearSDK has received the log file list retrieval request, it can synchronize the log file list retrieval 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, thereby notifying the second device to prepare to report log files. That is, the notification sent to the second device may refer to the log file list retrieval request information.

[0108] In 100b above, after receiving the log file list retrieval request, in addition to performing the synchronization operation described in 100a above, the WearSDK (more specifically, the log service in WearSDK) on the first device will also initiate a log file compression operation to compress multiple log files (which may be referred to as the master log file) in the first device into a single compressed log file (the first compressed log file). For specific implementation details, please refer to... Figure 5 By calling the compression module, multiple log files in the first device can be compressed together to obtain a first compressed log file (e.g., ...). Figure 5 The first compressed log file (.zip) will have a filename generated according to agreed-upon filename generation rules during the compression process. Specifically, the filename of the first compressed log file will include the device identifier of the first device. For example, taking zip (an archive file format that supports lossless data compression) compression as an example, the filename format of the first compressed log file could be: XXX_master.zip, where the master field in the filename represents the device identifier of the first device.

[0109] The logs in the log file of the first device mentioned above can be hashed logs generated by applications on the first device and then written to the corresponding log file, in order to further reduce the size of the log file. Based on this, the method provided in this embodiment may further include the following steps:

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

[0111] S12. Hash the logs generated by the application to obtain the hashed logs;

[0112] S13. Write the hashed log to the log file corresponding to the application.

[0113] In specific implementation, the applications on the first device include, but are not limited to, business applications, communication modules (such as Bluetooth modules), and power modules in the WearSDK. The services provided by the SDK include log services and other types of business services (such as data transceiver services (corresponding to the data transceiver module)). Logs generated by the applications on the first device can refer to logs generated by the corresponding applications during non-log reporting business interactions between the first device and the third device. Non-log reporting business interactions include, but are not limited to, device registration, power reporting, and information query interactions.

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

[0115] For example, when a user queries the first device's connection status, battery level, noise control information, sound effects, device information, quick operations, firmware updates, and user guide by operating a third device, the third device will generate a corresponding information query log; correspondingly, the device management module of WearSDK in the first device will generate a corresponding query response log.

[0116] For example, after the third device establishes a communication connection with the first device, it will synchronize some information, such as time information, to the first device. Furthermore, 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 and second devices. During this information synchronization process, the data transceiver modules related to WearSDK in the first and second devices will generate corresponding logs.

[0117] After the first device obtains the logs generated by its application, it can call its built-in log API with hashing functionality to perform hashing on the obtained logs (the raw logs) to obtain hashed logs, and then write the hashed logs to the application's corresponding log file for storage. Hash processing refers to taking input data of arbitrary length (in this example, the obtained log information), processing it through a hash algorithm, and obtaining a fixed-length output data (called a hash value, message digest).

[0118] In the above 100c, in response to the notification, the WearSDK (more specifically, the log service within WearSDK) on the second device will initiate a log file compression operation, compressing multiple log files (which can be referred to as slave log files) on the second device into a single compressed log file, i.e., the second compressed log file. The filename of the second compressed log file contains the device identifier corresponding to the second device. For example, the filename format of the second compressed log file can be: XXX_slave.zip, where the slave field in the filename represents the device identifier of the corresponding second device.

[0119] For a detailed description of the second device's log file compression operation, please refer to the relevant content regarding the first device's log file compression operation described in step 100b above. For a detailed description of the log files in the second device, please refer to the relevant content regarding the log files in the first device described in conjunction with steps S11 to S13 above.

[0120] Furthermore, after the first device compresses multiple log files together to obtain a first compressed log file, it can further divide the first compressed log file into smaller packets to facilitate subsequent reporting of the first compressed log file to the third device in response to requests from the third device. Therefore, the method provided in this embodiment may also include the following steps:

[0121] 100b_1. The first compressed log file is divided into multiple log data packets so that the first compressed log file can be subsequently packetized and reported to the third device; wherein, each packet of log data contains multiple log frames.

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

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

[0124] Similarly, the second device can also divide its second compressed log file into multiple log data packets. For a detailed description of how the second device divides its second compressed log file into multiple log data packets, please refer to the above description of the detailed implementation process of the first device dividing its second compressed log file into multiple log data packets.

[0125] Figure 8 An example of a compressed log file (which could be a first compressed log file or a second compressed log file) is shown.

[0126] As described above, after the WearSDK on the first device obtains the filename of the first compressed log file in the first device and the filename of the second compressed log file sent by each second device, it will separate each filename with a separator (such as a semicolon ";" or a comma ",") to generate a log file list.

[0127] For example, combining Figure 4aLet the filename of the first compressed log file in the first device be XXX_master.zip, the filename of the second compressed log file in the second device 21 be XXX_slave21.zip, and the filename of the second compressed log file in the second device 22 be XXX_slave22.zip. Then the generated log file list format can be: XXX_master.zip; XXX_slave21.zip; XXX_slave21.zip.

[0128] In step 102 above, the WearSDK on the first device can send the generated list of log files to the third device through the transmission channel between the first device and the third device.

[0129] In the above 103, the file information retrieval request is generated by the third device based on the received log file list. Specifically, after receiving the log file list, the third device can read the file names contained in the log file list, extract a file name from it to generate a file information retrieval request, and then send the file information retrieval request to the first device, so that the first device can trigger the corresponding operation based on the file name specified in the request.

[0130] In practice, the third device can retrieve filenames from the log file list according to a built-in filename retrieval strategy to generate a file information retrieval request. The filename retrieval strategy can be a sequential retrieval strategy or a random retrieval strategy; no limitation is made here.

[0131] For example, using a sequential retrieval strategy, the third device can select filenames from the log file list in the order they are arranged. For instance, continuing the previous example, if the filenames in the log file list are arranged in the following order: XXX_master.zip; XXX_slave21.zip; XXX_slave21.zip, then the third device can first retrieve the filename XXX_master.zip to generate a file information retrieval request, requesting the file information of the first compressed log file. After collecting the first compressed log file based on the received file information, the third device can then retrieve the next filename, XXX_slave21.zip, to generate another file information retrieval request, and so on.

[0132] Of course, the third device can also use a random retrieval strategy, randomly selecting a filename from the log file list to generate a file information retrieval request. In this embodiment, the preferred filename retrieval strategy is to retrieve the files sequentially according to their arrangement.

[0133] After receiving a file retrieval request, the first device will hand it over to its WearSDK for parsing. Based on the filename specified in the parsed request, it will determine whether a master-slave role switch (hereinafter referred to as master-slave switch) is required. Specifically, if the filename specified in the request contains the device identifier of a second device (the target second device), a master-slave switch is determined to be required; otherwise, if the filename contains the device identifier of the first device, a master-slave switch is determined not to be required. When a master-slave switch is determined to be required, the first device will trigger the execution of the "perform master-slave switch with the target second device" step in section 104 above, enabling the target second device to communicate and interact with the third device.

[0134] Specifically, in one feasible implementation, "performing a master-slave switch with the target second device" in step 104 above 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 master-slave switching;

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

[0137] In practice, the WearSDK on the first device can obtain the communication connection information between the first device and the third device through its log service. The first device then sends this communication connection information to the target second device through the corresponding master-slave transmission channel. Based on the received communication connection information between the first and third devices, the target second device initiates a communication connection request to the third device to establish a communication connection. After establishing a communication connection with the target second device, the third device disconnects its communication connection with the first device.

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

[0139] 1) Prohibiting spontaneous master-slave switching between devices is to prevent spontaneous master-slave switching logic from being triggered due to certain events (such as low device battery) during subsequent interaction with a third device to transmit the second compressed log file, thus affecting the transmission of log files.

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

[0141] The WearSDK on the target second device determines its current device role as a master device. Based on the saved current log file reporting status (file information pending reporting), it learns that it is currently in the file information reporting process and sends a query request to the log service to retrieve the file information of the second compressed log file on the target second device. The log service responds to the query request by sending the retrieved file information of the second compressed log file back to the WearSDK on the target second device. Further, the WearSDK on the target second device sends the received file information of the second compressed log file to the third device (specifically, to the log collection application on the third device). The file information of the second compressed log file includes, but is not limited to, the total file size (total file length) and verification information. This verification information is a checksum calculated by the target second device using a corresponding data verification algorithm (such as SHA256, CRC, MD5, etc.). This calculated checksum 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 packet collection of the second compressed log file from the target second device based on the total file size. After collection, the third device can use the verification information to perform integrity verification on the collected second compressed log file, thereby determining whether the collected second compressed log file has been tampered with or has lost frames.

[0142] For example, after the third device completes the packet collection operation for the second compressed log file, it can merge all the collected packet log data, thus obtaining the collected second compressed log file. Then, it uses its built-in data verification algorithm to calculate a value from the collected second compressed log file. This calculated value is compared with the received verification value to determine the completeness and validity of the collected second compressed log file. For example, if the calculated value is the same as the received verification value, it indicates that the collected second compressed log file is complete and valid; conversely, if the calculated value is different from the received verification value, it indicates that the collected second compressed log file is incomplete, and there may be problems such as data tampering or frame loss. In the case of an incomplete second compressed log file, the next operation can be determined based on the degree of incompleteness. For example, if the incompleteness exceeds a set threshold, it indicates a potentially large amount of data tampering and / or frame loss, which could lead to the loss of critical log information, rendering the collected second compressed log file invalid. In this case, the second compressed log file can be re-collected in packets. Conversely, if the incompleteness is less than or equal to the set threshold, it indicates a smaller potential amount of data tampering and / or frame loss, making the possibility of losing critical log information extremely low. The collected second compressed log file can be considered a valid log file and does not need to be re-collected. The degree of incompleteness of the collected second compressed log file can be determined, but is not limited to, based on the difference between the calculated value and the received checksum.

[0143] It should be noted that the data verification algorithm used by the third device matches the data verification algorithm used by the target second device. For example, if the target second device uses a CRC checksum algorithm, then the third device also uses a CRC checksum algorithm.

[0144] The current log file reporting status stored in the target second device is communicated to the target second device by the first device. Therefore, when the specified filename contains the device identifier of the target second device, 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 current log file reporting status is that the file information of the second compressed log file is pending reporting.

[0146] For a detailed description of the implementation of the third device performing the packet collection operation of the second compressed log file on the target second device, please refer to the relevant content of the third device performing the packet collection operation of the first compressed log file on the first device described below, which will not be repeated here.

[0147] After the third device completes the collection of the second compressed log file from the target second device, it will send the log file collection result to the target second device to notify it that the log file transmission is complete. Once the target second device confirms the completion of the log file transmission based on the received notification, it will lift the restriction on spontaneous master-slave failover.

[0148] The technical solution provided in this embodiment involves a first device (master device) generating a log file list and sending it to the third device when it detects that the conditions for reporting log files to the third device are met. This list is based on the filenames of the first compressed log files in the first device and the filenames of the second compressed log files in at least one second device (slave device). Furthermore, in response to a file information retrieval request sent by the third device based on the log file list, the first device determines the filename specified in the request. If the specified filename contains the device identifier of the target second device, a master-slave switch is performed with the target second device (one of at least one second device), causing the target second device to become the master device and communicate with the third device. This allows the target second device to send the file information of the second compressed log files in the target second device to the third device, so that the third device can subsequently perform packet collection operations of the second compressed log files based on the received file information. In the scenario of master-slave device log reporting, this solution introduces a master-slave device role switch before the slave device logs are reported, turning the slave device into the master device. This allows the slave device to directly report its log files to the third device without having to report them through the original master device. This effectively shortens the log reporting process of the slave device, thereby reducing the time required for log reporting and improving log reporting efficiency.

[0149] Furthermore, if the first device determines that the filename specified in the received file information retrieval request contains the device identifier of the first device, then 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 to the third device. That is, the method provided in this embodiment further includes the following steps:

[0150] 105. If the specified file name contains 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 transmission parameters negotiated with the first device.

[0151] The file information of the aforementioned first compressed log file includes the total file size and verification information. This verification information is used by the third device to verify the collected first compressed log file. For a detailed description of how the file information of the first compressed log file is obtained, please refer to the above-described content regarding the acquisition of the file information of the second compressed log file by the target second device.

[0152] The log file transmission parameters mentioned above include at least one of the following: maximum transmission length, frame length of the frame log, transmission interval duration, and retransmission support. The maximum transmission length is equal to the frame length multiplied by the maximum number of frame log frames that can be transmitted for a single log data retrieval request. The maximum number of frames can be 8 frames or 16 frames, etc. For details regarding the maximum number of frames, please refer to the relevant content in other embodiments. Retransmission support refers to whether bitmap-based log retransmission is supported; more specifically, it refers to whether bitmap-based selective log retransmission is supported. In addition, the log file transmission parameters may also include other parameters, such as the transmission protocol version.

[0153] After receiving the file information of the first compressed log file, the third device will, based on the total file size and log file transmission parameters of the first compressed log file in the file information, begin sending log data retrieval requests to the first device to collect the first compressed log file in packets. Each log data retrieval request requests one packet of log data from the multiple packets included in the first compressed log file, and continues until the collection of the first compressed log file is complete. Furthermore, after collection, the verification information in the file information can be used to verify whether the collected first compressed log file is complete and valid. For a detailed description of the verification implementation, please refer to the section on verifying the collected second compressed log file described above; it will not be repeated here.

[0154] In specific implementation, when the retransmission support included in the log file transmission parameters is to support bitmap-based log retransmission, during the process of the third device performing packet collection operation of the first compressed log file on the first device, each log data acquisition request sent to the first device will carry a frame log bitmap. Each bit in the frame log bitmap is used to store the received status of the corresponding frame log.

[0155] Taking a maximum of 8 frames as an example, the frame log bitmap can be 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 include a frame log bitmap in a log data retrieval request will be detailed below.

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

[0160] 106. Receive the 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 requested target packet log data; the frame log bitmap represents a portion of the frame logs in the target packet log data that needs to be retransmitted or represents all the frame logs in the target packet log data that needs to be uploaded; the target packet log data is one packet of log data among the multiple packets of log data included in the first compressed log file;

[0161] 107. Based on the starting offset and the data size, obtain the target packet log data from the multi-packet log data included in the first compressed log file;

[0162] 108. If the frame log bitmap represents a portion of the frame logs in the target packet log data that need to be retransmitted, then the frame number of the frame logs that need to be retransmitted is determined according to the frame log bitmap; based on the frame number and the negotiated frame length, multiple frames of logs in the target packet log data are selectively retransmitted to the third device.

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

[0164] To facilitate understanding of steps 106-109 above, a detailed description is provided below. The following description uses the example of the first device continuously sending 8 log frames for a single log data acquisition request.

[0165] The third device sends a first log data retrieval request (initial log data retrieval request) to the first device based on 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 retrieval request is used to request the first packet of log data, which is the first in the sequence of multiple packets of log data in the first compressed log file. Accordingly, the first log data retrieval request carries a starting offset of 0, a data size equal to the negotiated maximum transmission length, and all bits in the frame log bitmap set to 0 (as shown in Table 1, indicating that this request is for a new packet of log data, requiring the uploading of all frame logs in the requested packet of log data (the first packet of log data)). After receiving the above first log data retrieval request, the first device, through parsing, determines, based on the starting offset and data size carried in the request, that the requested data is the first packet of log data in the first compressed log file (as shown in Table 1). Figure 8The first device will send the multi-frame logs in the first packet of log data to the third device frame by frame according to the negotiated frame length, based on the frame log bitmap carried in the request. The sent frame logs will carry a PSN field that represents 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 frame log in the corresponding frame log bitmap according to the PSN field.

[0166] For example, the starting offset of the first log frame in the first log packet is the starting offset 0 of the first log packet, and the ending offset is the starting offset plus the frame length. Based on the starting and ending offsets of the first log frame, the first device can send the first log frame in the first log packet to the third device. The PSN field of the first log frame can be 0, indicating that the currently sent frame is the 0th frame (i.e., the first log frame) in the first log packet. The third device, based on the frame number 0 (i.e., the PSN field is 0) carried in the received first log frame, will set the value of bit 0 corresponding to frame number 0 in the frame log bitmap shown in Table 1 to a received value (e.g., 1). Similarly, the first device can send other log frames in the first log packet to the third device, and the third device can also set the corresponding bit values ​​in the frame log bitmap shown in Table 1 for the received other log frames.

[0167] When the 7th log frame (carrying the log frame with frame number 7) is received or the waiting time expires (exceeding the negotiated transmission interval), the next log data acquisition request process will be triggered.

[0168] Suppose that when the timing for triggering the next log data acquisition request process is reached, the third device fails to receive the 4th and 6th log frames in the first packet of log data, meaning that frames 4 and 6 were lost during transmission, then the final frame log bitmap obtained for the first packet of log data is 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 and send it to the first device according to the starting offset, data size, and frame log bitmap of the first log data packet. That is, the starting offset carried in the second log data acquisition request is equal to the starting offset of the first log data packet carried in the first log data acquisition request, the data size carried is equal to the data size carried in the first log data acquisition request, and the frame log bitmap carried is the final frame log bitmap corresponding to the first log data packet obtained through the first log data acquisition request (as shown in Table 2). The frame log bitmap carried this time indicates that a portion of the frame log in the first log data packet needs to be retransmitted.

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

[0173] Furthermore, assuming that when the timing for triggering the next log data acquisition request process is reached, the third device receives all frame logs from the first packet of log data, meaning there are no frame drops during the transmission of the first packet of log data, then the final frame log bitmap obtained for the first packet of log data is 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 retrieval request to the first device for the second packet of log data in the first compressed log file. The starting offset of the second packet of log data carried in this second log data retrieval request equals the starting offset of the first packet of log data carried in the first log data retrieval request plus the data size of the first packet of log data. In other words, the starting offset of the second packet of log data carried is equal to the ending offset of the first packet of log data. Furthermore, all bits in the frame log bitmap of the second packet of log data carried are 0 (as shown in Table 1, indicating a new packet of log data retrieval request, requiring the uploading of all frame logs in the second packet of log data). The data size of the second packet of log data carried in the second log data retrieval request is related to the following two factors: whether the second packet of log data is the last packet of log data, and whether the total file size of the first compressed log file is divisible by the negotiated maximum transmission length allowed for the third device. If the second packet of log data is not the last packet of log data in the first compressed log file, then the data size carried in the second log data retrieval request is the maximum transmission length. If the first log data packet is the last log data packet in the second compressed log file, and the total file size of the first compressed log file cannot be divided by the negotiated maximum transmission length, then the data size carried in the second log data retrieval 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 log data packet).

[0177] After receiving the second log data retrieval request, the first device, based on the frame log bitmap carried in the request, can determine that all frame logs in the second packet of log data need to be uploaded. Based on this, the first device can send the multiple frame logs from the second packet of log data to the third device frame by frame, according to the frame length, until the transmission is complete. Correspondingly, the third device will mark the received frame logs with a received status in the corresponding bit of the frame log bitmap of the second packet of log data.

[0178] This process continues until the first compressed log file has been reported.

[0179] As can be seen from the above, this solution introduces a bitmap-based selective retransmission mechanism in the log file reporting process. This allows the system to determine whether any frames were lost during the transmission of log data for a given log data retrieval request, and which specific log frames were lost, based on the bit information recorded in the bitmap (frame log bitmap). This enables the system to quickly retransmit the lost log frames when responding to the next log data retrieval request.

[0180] Furthermore, to avoid repeated requests for the same packet of log data, this embodiment also adds an interception mechanism for such requests, setting a policy of not processing requests exceeding a certain number of times. Therefore, before performing step 107 above, the method provided in this embodiment may further include the following steps:

[0181] S31. Determine the number of times a log data retrieval request carrying the starting offset is received;

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

[0183] S33. When the number of times exceeds the preset number of times, the log data acquisition request will not be responded to, but the log data acquisition request may be recorded.

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

[0185] Figure 9 A flowchart illustrating a log reporting method according to another embodiment of this application is shown. The execution entity for all steps in the method described in this embodiment may be the target second device; more specifically, the steps in the method may be executed by a service component (WearSDK) in the target second device. The target second device is one of at least one second device in the aforementioned system. At least one second device is a slave device communicating with the first device as a master-slave. The first device also communicates with a third device that has log file collection functionality. For a description of the first device, second device, third device, and their communication methods, please refer to relevant content in other embodiments. See also... Figure 9 The log reporting method provided in this embodiment includes the following steps:

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

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

[0188] 203. Establish a communication connection with the third device based on the communication connection information;

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

[0190] Wherein, the communication connection information is sent by the first device when it performs a master-slave switch with the target second device after determining 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 based on the received log file list; the log file list is generated by the first device based on the file name of the first compressed log file in the first device and the file name of the second compressed log file in 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 slave device to master device, and the third device disconnects the communication connection with the first device.

[0191] Furthermore, the method provided in this embodiment also includes the following steps:

[0192] 205. After establishing a communication connection with the third device, the target second device is prohibited from spontaneously switching between master and slave.

[0193] Furthermore, the method provided in this embodiment may also include the following steps:

[0194] 206. Receive the log data acquisition request sent by the third device for the second compressed log file; wherein the log data acquisition request carries the starting 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 in the multi-packet log data included in the second compressed log file;

[0195] 207. Based on the starting offset and the data size, obtain the target packet log data from the multi-packet log data included in the second compressed log file;

[0196] 208. If the frame log bitmap represents a portion of the frame logs in the target packet log data that need to be retransmitted, then the frame number of the frame logs that need to be retransmitted is determined according to the frame log bitmap; based on the frame number and the negotiated frame length, multiple frames of logs in the target packet log data are selectively retransmitted to the third device.

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

[0198] In specific implementation, the third device sends a log data retrieval request to the target second device based on the file information (more specifically, the total file size contained in the file information) of the second compressed log file received from the target second device and the negotiated log file transmission parameters. Each log data retrieval request requests one packet of log data. The log file transmission parameters can be negotiated between the third device and the first device. When a master-slave switch is determined, the first device can synchronize the negotiated log file transmission parameters to the target second device. Of course, considering that the Bluetooth module in the target second device and the Bluetooth module in the first device may support different transmission performances due to differences, such as different Bluetooth module protocol versions, in some instances, the third device can renegotiate the log file transmission parameters with the target second device after establishing a communication connection. For a detailed description of the implementation of the third device renegotiating the log file transmission parameters with the target second device, please refer to the relevant content on the negotiation of log file transmission parameters between the third device and the first device described in other embodiments of this application. Preferably, in this embodiment, during the entire log reporting process, the third device only negotiates the log file transmission parameters with the first device once.

[0199] For a detailed description of steps 206 to 209 above, please refer to the relevant content in other embodiments of this application describing the reporting of the first compressed log file of the first device to the third device, such as the content related to steps 106 to 109 in other embodiments.

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

[0201] 210. After receiving the notification from the third device that the collection of the second compressed log file is complete, the restriction on the target second device to automatically perform master-slave switching is lifted.

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

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

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

[0205] Furthermore, the method provided in this embodiment also 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 log to obtain the hash-processed log;

[0208] 200a0_3. Write the hashed log to the log file corresponding to the application.

[0209] For a detailed description of the implementation of each step in the method provided in this embodiment, please refer to the relevant content in other embodiments of this application, which will not be repeated here. Furthermore, in addition to the steps given above, the method provided in this embodiment may also include other steps. For details of these other steps and their specific implementation, please refer to the relevant content in other embodiments of this application.

[0210] Figure 10 This diagram illustrates a flowchart of a log reporting method according to another embodiment of this application. In this embodiment, the executing entity for all steps is a third device in the aforementioned system. More specifically, it can be an application with log collection functionality installed on the third device (referred to as a log collection application, such as a smart space application). The third device is communicatively connected to the first device, and the first device engages in master-slave communication with at least one second device, where the first device is the master device and the second device is the slave device. See also... Figure 10 The log reporting method provided in this application includes the following steps:

[0211] 301. Display the interactive interface;

[0212] 302. In response to the user's operation triggered through the interactive interface, send a log file list retrieval request to the first device selected by the user that needs to report logs;

[0213] 303. Based on the log file list received from the first device, send a file information retrieval request to the first device;

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

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

[0216] 306. Based on the file information and log file transmission parameters of the second compressed log file, perform a packet collection operation on the target second device for the second compressed log file;

[0217] Wherein, the first device is a master device that performs master-slave communication with at least one second device; the log file list is generated by the first device based on the filenames of the first compressed log files in the first device and the filenames 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 device; the target second device sends a communication connection request to the third device based on the communication connection information between the first device and the third device sent by the first device; the first device sends the communication connection information to the target second device when it determines that the filename specified in the received file information acquisition request contains the device identifier of the target second device and performs a master-slave switch with the target second device.

[0218] In the above 301-302, the interactive interface may refer to the problem feedback interface provided by a log collection application (such as a smart space application) on a third device, such as... Figure 7 As shown in the diagram. Through this interactive interface, users can trigger problem feedback operations to select the device for which problem feedback is needed (i.e., the device that needs to be logged), input a description of the device problem, etc. For a detailed description of the user's operations through this interactive interface, please refer to relevant content in other embodiments of this application.

[0219] For a detailed description of the implementation of steps 303 to 306 above, please refer to the relevant content in other embodiments of this application.

[0220] In step 306 above, the file information of the second compressed log file includes: total file size and verification information. This verification information is used by the third device to verify the collected second compressed log file. The log file transmission parameters include: maximum transmission length, frame length of the frame log, transmission interval duration, and retransmission support. The maximum transmission length is equal to the frame length multiplied by the maximum number of frame log frames that can be continuously transmitted for a single log data acquisition request. For a detailed description of the log file transmission parameters, please refer to the relevant content in other embodiments of this application.

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

[0222] 3061. Based on the file information and log file transmission parameters of the second compressed log file, send a log data acquisition request to the target second device; 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, wherein 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 log sent by the target second device in response to this request;

[0224] 3063. Determine the frame number of the received frame log based on the information carried in the received frame log;

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

[0226] 3065. When the time is right to send the next log data acquisition request, determine the parameters that the next request needs to carry based on the frame log bitmap corresponding to this request, until the second compressed log file collection is completed.

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

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

[0229] 30651. Based on the frame log bitmap corresponding to this request, determine whether there are any frame drops in the target packet log data requested this time;

[0230] 3065. When frame loss occurs, the starting offset, data size, and corresponding frame log bitmap of the target packet log data of this request are respectively determined 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] 3066. When there are no frame drops, the sum of the starting offset and the data size of the target packet log data in the current request is used to determine the starting offset of the target packet log data to be carried in the next request. All bits in the frame log bitmap to be carried in the next request must be values ​​that were not received (e.g., all must be the second value, such as 0), and the data size must be 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. Specifically, if the total file size is not divisible by the maximum transmission length, and the target packet log data for the next request is the last packet log data in the second compressed log file (i.e., the last packet log data in the sequence), then 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 size 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, then the data size to be carried in the next request is the maximum transmission length.

[0232] For a detailed description of the implementation of each step in the method provided in this embodiment, please refer to the relevant content in other embodiments of this application, which will not be repeated here. Furthermore, in addition to the steps given above, the method provided in this embodiment may also include other steps. For details of these other steps and their specific implementation, please refer to the relevant content in other embodiments of this application.

[0233] This application also provides two other embodiments of a log reporting method. The execution entity for all steps in these two embodiments can be the first device in the aforementioned system, or more specifically, a service component (WearSDK) within the first device. The first device establishes a communication connection with a third device, which is used for log file collection. For detailed descriptions of the first and third devices and their communication methods, please refer to relevant content in other embodiments of this application. Specifically, the log reporting methods provided in the other two embodiments of this application are as follows:

[0234] See also Figure 11 One embodiment of the log reporting method includes the following steps:

[0235] 401. 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 starting 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 indicates that all frame logs in the target packet log data need to be uploaded;

[0236] 402. Based on the starting offset and the data size, obtain the target packet log data from the multi-packet log data included in the first compressed log file;

[0237] 403. If the frame log bitmap represents a portion of the frame logs in the target packet log data that need to be retransmitted, then the frame number of the frame logs that need to be retransmitted is determined according to the frame log bitmap; based on the frame number and the negotiated frame length, multiple frames of logs in the target packet log data are selectively retransmitted to the third device.

[0238] 404. If the frame log bitmap represents that all frame logs in the target packet log data need to be uploaded, then the multiple frame logs in the target packet log data are sent to the third device frame by frame.

[0239] Furthermore, the method provided in this embodiment also includes the following steps:

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

[0241] 400b. The negotiation result of the log file transmission parameters is sent to the third device, so that the third device can send a log data acquisition request to the first device for the first compressed log file based on the negotiated log file transmission parameters and the file information of the first compressed log file.

[0242] The log file transmission parameters include at least one of the following: maximum transmission length, frame length of the frame log, transmission interval duration, and retransmission support request; the maximum transmission length is equal to the frame length multiplied by the maximum number of frame log frames that can be continuously transmitted for a single log data acquisition request; when the retransmission support request supports bitmap-based log retransmission, the log data acquisition request sent by the third device carries a frame log bitmap.

[0243] For a detailed description of the implementation of each step in the method provided in this embodiment, please refer to the relevant content in other embodiments of this application, which will not be repeated here. Furthermore, in addition to the steps given above, the method provided in this embodiment may also include other steps. For details of these other steps and their specific implementation, please refer to the relevant content in other embodiments of this application.

[0244] See also Figure 12 Another embodiment of the log reporting method 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 log to the log file corresponding to the application;

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

[0249] 505. Send the file information of the first compressed log file to the third device, so that the third device can perform a packet collection operation of the first compressed log file on the first device according to the file information.

[0250] Furthermore, the first device also establishes a master-slave communication connection with at least one second device, wherein the first device is the master device in the master-slave communication connection; and when the condition for reporting the log file to the third device is detected, the method provided in this embodiment further includes the following steps:

[0251] A11. Send a notification to each of the at least one second device to inform it of the read / write log file preparation.

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

[0253] A13. Generate a log file list based on the filename of the first compressed log file and the filename of the received second compressed log file;

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

[0255] The first compressed log file contains the device identifier of the first device in its filename; the second compressed log file is obtained by the second device responding to the notification by compressing all its log files together; the filename of the second compressed log file contains the device identifier of the second device.

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

[0257] 5051. In response to the file information retrieval request sent by the third device based on the log file list, determine the file name specified in the request;

[0258] 5052. If the specified file name contains the device identifier of the first device, then 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] The file information of the first compressed log file includes: total file size and verification information. The verification information is used by the third device to verify the second compressed log file collected.

[0260] For a detailed description of the implementation of each step in the method provided in this embodiment, please refer to the relevant content in other embodiments of this application, which will not be repeated here. Furthermore, in addition to the steps given above, the method provided in this embodiment may also include other steps. For details of these other steps and their specific implementation, please refer 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. Regarding the issue of time-consuming log file reporting, the technical solution adopted in this application is as follows:

[0263] 1.1 A hashing and compression scheme for logs is introduced into WearSDK to reduce log size. Specifically:

[0264] See Figure 5 For logs generated by applications 1 to N on the Bluetooth thin device (including 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 hashes the logs using the log API interface with Hash functionality and writes them to the corresponding application's Hash log file. Further, after the Bluetooth rich device triggers the log reporting process, WearSDK on the Bluetooth thin device receives a log reporting request from the Bluetooth rich device (the log file list retrieval request mentioned in the context), and notifies the log service in WearSDK on the Bluetooth thin device to call the compression module to perform log file compression, compressing Hash log files 1 to Hash log files N into a single log file .zip (the first compressed log file) and outputting it. Further still, through WearSDK and the Bluetooth module on the Bluetooth thin device, the output log file .zip is reported to the Bluetooth rich device, and finally transmitted to the corresponding APP on the Bluetooth rich device (the log collection application, such as the smart space application) for subsequent processing.

[0265] 1.2 In master-slave device log reporting scenarios, a master-slave failover mechanism is introduced. See [link / reference] Figure 4b The details are as follows:

[0266] 1) The APP (log collection application) on the Bluetooth rich device triggers the log reporting process. Specifically, when a user encounters an error while using a Bluetooth thin device (including a Bluetooth master device (hereinafter referred to as the master device) and a Bluetooth slave device (hereinafter referred to as the slave device, such as slave device 1 and slave device 2)), they can select the Bluetooth thin device for which they want to report the problem at the problem feedback entry in the APP, fill in a description of the specific problem that occurred on the Bluetooth thin device, and click confirm after completing the form; the APP responds to this confirmation operation by sending a request for device logs (a log file list retrieval request) to the Bluetooth thin device side (sent to the master device) through the Bluetooth module on the Bluetooth rich device;

[0267] 2) Communication between the Bluetooth module in the Bluetooth rich device and the Bluetooth module in the Bluetooth master device. Before the Bluetooth rich device and the Bluetooth master device interact for log file collection, the user has already paired and connected them. At this time, the Bluetooth rich device and the Bluetooth master device can provide a stable Bluetooth transmission channel for log reporting. Before the APP on the Bluetooth rich device interacts with the WearSDK on the Bluetooth master device, it will create a Bluetooth service channel with a UUID of XXXX for log reporting.

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

[0269] 4) The WearSDK on the Bluetooth master device parses data and processes corresponding requests or responses. After receiving the binary byte stream data sent by the Bluetooth master device through its Bluetooth module, the WearSDK on the Bluetooth master device parses internal proprietary protocols (such as the MBB protocol) to identify the specific service type (log service) and request type (log file information), and parses out the requested filename information. For example, if the filename information is xxx_master.log, the presence of the "master" field in the filename indicates a request for logs from the Bluetooth master device. In this case, it directly retrieves the total file size and verification information (used by the Bluetooth rich device to verify the collected log files) from the Bluetooth master device and returns this file information to the APP on the Bluetooth rich device via the 4-3-2-1 transmission path. The APP then requests the log file content from the Bluetooth master device via the 1-2-3-4 transmission path based on the received file information. After receiving the log file content request, the WearSDK on the Bluetooth master device then reports the log file content to the APP on the Bluetooth rich device via the 4-3-2-1 transmission path.

[0270] 5.1) Bluetooth Master / Slave Device Role Switching. If, in step 4) above, the WearSDK on the Bluetooth master device parses the requested filename information (e.g., xxx_slave1.log) and identifies the `slave1` field in the filename, it indicates that the request is for the logs of Bluetooth slave device 1. In this case, the WearSDK on the Bluetooth master device will call the interface provided by the Bluetooth master device to inform it to switch master / slave roles. The Bluetooth master device will then send its pairing information (communication connection information) with the Bluetooth rich device to Bluetooth slave device 1, allowing Bluetooth slave device 1 to pair and connect with the Bluetooth rich device based on the received pairing information. After successful master / slave role switching, Bluetooth slave device 1 becomes the new Bluetooth master device and interacts with the Bluetooth rich device for log reporting. During log reporting interaction, spontaneous master / slave role switching is prohibited. The original Bluetooth master device will disconnect from 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 WearSDK, and the specific implementation is the same as described in 3) above.

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

[0273] 6.1) Bluetooth Master / Slave Device Role Switching. If, in step 4) above, the WearSDK on the Bluetooth master device parses the requested filename information (e.g., xxx_slave2log), it will recognize the "slave2" field in the filename, indicating that the request is for the logs of Bluetooth slave device 2. The WearSDK on the Bluetooth master device will then call the interface provided by the Bluetooth master device to initiate a master-slave switch. The Bluetooth master device will then send its pairing information (communication connection information) with the Bluetooth rich device to Bluetooth slave device 2, allowing Bluetooth slave device 2 to pair and connect with the Bluetooth rich device based on the received pairing information. After the master-slave role switch is successful, Bluetooth slave device 2 becomes the new Bluetooth master device and interacts with the Bluetooth rich device for log reporting. During this log reporting interaction, spontaneous master-slave role switching is prohibited. The original Bluetooth master device will disconnect from 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 WearSDK, with the specific implementation being the same as described in 3) above.

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

[0276] In summary, this solution, by introducing a master-slave device role switching scheme in the master-slave device log reporting scenario, can reduce the number of steps in the slave device log reporting process compared to existing technical solutions, achieving the same effect as the master device log reporting process.

[0277] 2. To address the potential frame loss issue during log file reporting, this application employs a bitmap-based log retransmission mechanism, implemented as follows:

[0278] See also Figure 8The Bluetooth thin device divides the log file (more specifically, the compressed log file) into N log data packets (Package1 to PackageN). During the log reporting service interaction, the APP on the Bluetooth rich device requests one packet of log data each time, and the Bluetooth thin device responds by returning one packet of log data. Each packet contains multiple log frames (e.g., 8 or 16 frames). The specific number of log frames in one packet is determined by the WearSDK vendor based on the size of the Bluetooth module's transmission buffer. If the buffer is large, 16 frames can be selected; otherwise, 8 frames are selected. This application uses 8 frames for illustration. After receiving the request for one packet of log data from the APP on the Bluetooth rich device, the Bluetooth thin device continuously sends the corresponding 8 log frames to the APP. Each log frame carries a PSN field, indicating which frame is being sent, according to internal proprietary protocols such as the MBB protocol. Upon receiving each log frame, the APP sets the corresponding bit in the bitmap to 1 based on the PSN information, indicating that the current log frame has been received. As shown in Table 2, the bitmap indicates that in this log data acquisition request interaction, frames 4 and 6 of the requested log data packet were not received. Furthermore, based on this bitmap information, the app on the Bluetooth rich device will include this bitmap information in the next log data acquisition request, setting the starting offset and data size of the requested log data packet to the same as those of the previous request. Upon receiving the next request, the Bluetooth device, based on the starting offset and bitmap information carried in the request, can determine which log frames were lost during the log transmission for the previous log data acquisition request. Therefore, in response to this next request, it can quickly resend the lost log frames to the app on the Bluetooth rich device.

[0279] The following section will introduce the solution of this application using a specific application scenario to facilitate a better understanding of the solution. In the process of introducing the solution below, we will combine... Figure 13a and Figure 13b The illustrated log reporting sequence diagram uses a mobile phone as the rich device and a master-slave Bluetooth headset as the thin device as an example. The Bluetooth headset consists of two earpieces, a left and a right earpiece. Generally, the left earpiece is the master earpiece (i.e., the master device), and the right earpiece is the slave earpiece (i.e., the slave device). When the mobile phone pairs with the Bluetooth headset via the Bluetooth module, it pairs with the left earpiece, and the left earpiece then pairs with the right earpiece. Figure 13a and Figure 13bThe process is mainly divided into two parts: log reporting from the master and slave devices (the left and right earpieces of the Bluetooth headset) to the mobile phone. Steps starting with "M" primarily involve interaction between the mobile phone and the left earpiece; steps starting with "D" primarily involve interaction between the left and right earpieces; steps starting with "S" primarily involve interaction between the mobile phone and the right earpiece; steps starting with "M'" involve interaction between the mobile phone and the new master device (the original slave device (right earpiece) becomes the new master device); and steps starting with "S'" primarily involve interaction between the mobile phone and the new slave device (the original master device (left earpiece) becomes the new slave device). These two interaction processes—between the mobile phone and the new master device, and between the mobile phone and the original master device—are independent and decoupled, but the interaction process between the mobile phones themselves is the same.

[0280] like Figure 13a and Figure 13b The log reporting process provided in this application is as follows:

[0281] 1. Log generation phase

[0282] M1: The 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 and right earbuds establish a pairing connection, which is a master-slave pairing connection. Specifically, it is a Bluetooth pairing connection established based on the Bluetooth protocol; where the left earbud is the master device and the right earbud is the slave device.

[0284] M2: The mobile phone interacts with the left earpiece for non-log reporting services, such as device registration, battery reporting, information query, etc. During the service interaction, the corresponding registration module and device management module on the mobile phone will generate service logs, and the corresponding service module on the left earpiece (such as the service application corresponding to WearSDK on it) will also generate corresponding log information.

[0285] D2: Master-Slave Device Interaction. After the left and right earbuds are paired and connected, the left earbud will synchronize some information, such as time information, to the right earbud 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 WearSDK related data transceiver module on the right earbud (as a Bluetooth slave device) and the corresponding data receiving / transmitting module on the speaker (as a Bluetooth master device) will generate relevant log information.

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

[0287] M3: Log Hash Processing of the Main Device. For the raw logs generated in steps M2 and D2, the left earpiece will perform hash processing on the raw logs through its hash log API, and then write the hash-processed logs to the corresponding log files for storage in step M3.1;

[0288] S1: Log hashing from the device. The right earpiece will hash the original log generated in step D2.1 using its Hash log API, and then write the hashed log to the corresponding log file for storage in step S1.1.

[0289] 3. Log file reporting stage

[0290] Users can access the Smart Space application (hereinafter referred to as the APP) on their mobile phones, click on "Problem Feedback," and report any issues encountered while using the Bluetooth headset. After filling in a description of the problem, the probability of its occurrence, and other information, clicking "Submit" will trigger the APP's process of collecting logs from the Bluetooth headset. Details are as follows:

[0291] M4: The mobile app sends a log file list retrieval request to the left earpiece. Based on internal proprietary protocols, such as the MBB protocol, the app encapsulates the log file list retrieval request information into a protocol message and then sends the protocol message (the log file list retrieval request information) to the left earpiece via the phone's Bluetooth module.

[0292] M4.1: The WearSDK on the left earbud parses the received protocol message (log file list retrieval request) and notifies the right earbud to prepare to report the log file. Specifically, after the Bluetooth module on the phone sends the protocol message to the left earbud, it is first received by the Bluetooth module on the left earbud and passed to the WearSDK on the left earbud. After receiving the protocol message, the WearSDK on the left earbud parses the protocol message based on its internal proprietary protocols (such as the MBB protocol), and after confirming that the protocol message is a log file list retrieval request, it synchronously informs the right earbud of the log file list retrieval request information through the external interface.

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

[0294] S2.1: The right earphone compresses its internal log files. After the right earphone receives the log file list retrieval request synchronized from the left earphone, the log service in its WearSDK (i.e., the log service module in the diagram, also known as the device log management service module) will initiate the log file compression action, compressing multiple log files (slave log files) in the right earphone into a single compressed log file, such as xxx_slave.zip (this is an example of using zip compression (the resulting compressed log file has a .zip extension), unless otherwise specified, the compression involved will also use zip compression as an example). The WearSDK integration development documentation stipulates that the slave field is included in the slave device log, and the compressed file extension is a regular compressed file extension.

[0295] S2.2: The right earphone reports the filename of its log file. After the right earphone compresses its log file, it will synchronize the filename of the generated compressed log file, xxx_slave.zip, to the left earphone (i.e., step D3.2 in Figure 13) through the master-slave transmission channel established in step D1;

[0296] M4.2: The left earphone compresses its internal log files. After receiving a log file list request, the log service in its WearSDK (i.e., the log service module in the diagram, also known as the device log management service module) initiates the log file compression process, compressing multiple log files (master ear log files) in the left earphone into a single compressed log file, such as xxx_master.zip (this is an example of using zip compression (the resulting compressed log file has a .zip extension)). The WearSDK integration development documentation specifies that the Bluetooth master device (left earphone) logs include the "master" field, and the compressed file extension is a standard compressed file extension.

[0297] M4.3: The log file lists for the left and right earpieces are returned to WearSDK. The logging service in WearSDK on the left earpiece separates the filenames of the compressed log files in the left earpiece and the filenames of the received log files from the right earpiece with a semicolon ";", forming a log file list as follows: xxx_master.zip; xxx_slave.zip, and returns this log file list to WearSDK on the left earpiece;

[0298] M4.4: Responding to the log file list retrieval request sent by the APP on the mobile phone. The WearSDK on the left earphone will encapsulate the log file list information obtained in step M4.3 based on the internal proprietary related protocol (MBB protocol) and send it to the APP on the mobile phone through the Bluetooth module on the left earphone;

[0299] M5: Negotiating Log File Transmission Parameters. The mobile app and the left earpiece negotiate the log file transmission parameters for uploading the log file from the earpiece device to the mobile app. These parameters include the maximum transmission length allowed by the app, the frame length (i.e., frame size) of each log frame, the transmission interval, whether retransmission is supported, and the protocol version. After receiving the negotiation parameter request from the app, the left earpiece passes it to its WearSDK for protocol parsing and reports the negotiation result to the app (corresponding to step M5.1 in the diagram). The maximum transmission length allowed by the app = frame length of the log frame * the maximum number of frames that can be continuously transmitted for a single log data acquisition request (e.g., 8 or 16 frames); whether retransmission is supported refers to whether selective retransmission based on a bitmap is supported.

[0300] M6: Retrieve Single File Information (i.e., retrieve file information for a single log file). The APP sends a file information retrieval request to the left earpiece based on the received log file list. The file information retrieval request carries the specified filename. If the specified filename is, for example, xxx_master.zip, it indicates that it needs to request file information of compressed log files in the left earpiece to obtain the total file size of compressed log files in the left earpiece. After receiving this file information retrieval request, the left earpiece hands the file information retrieval request to its WearSDK for protocol parsing. After confirming that it is requesting file information of log files in the left earpiece, it queries the log service in step M6.1 to query information such as the total file size of compressed log files in the left earpiece, and then reports the query results to the APP on the mobile phone through steps M6.2 and M6.3.

[0301] M7: Request Log File Data. After receiving information such as the total file size of the compressed log file in the left earpiece, the mobile app will negotiate transmission parameters (i.e., negotiated log file transmission parameters) with the first device through step M5. Based on the negotiated transmission parameter result (corresponding to step M5.1 response in the diagram, representing the transmission parameter negotiation result returned by the left earpiece), it will send a log data retrieval request to the left earpiece. Specifically, if it is determined through negotiation that the earpiece device supports retransmission, the mobile app will include a bitmap field (frame log bitmap field; in the first request, all bits in the bitmap are 0, indicating that each frame of log data in the requested packet needs to be uploaded) in the request when sending the log data retrieval request to the left earpiece. Simultaneously, the request will also include the starting offset of the requested packet of log data (the starting offset is 0 in the first request) and the data size. The data size is generally the maximum transmission length allowed for the app to request, negotiated through step M5. The total file size may not be divisible by the maximum transmission length allowed for the APP negotiated in step M5. In this scenario, when the log data retrieval request requests the last packet of log data in the compressed log file of the left earpiece, the data size will be less than the maximum transmission length allowed for the APP negotiated in step M5 (data size = total file size of the compressed log file in the left earpiece minus the size of the log data already reported in the compressed log file of the left earpiece). After receiving the log retrieval request, the left earpiece, based on the starting offset, data size, and frame length negotiated in step M5, sends the requested packet of log data from the compressed log file in the left earpiece frame by frame to the APP on the mobile phone (corresponding to...). Figure 13a (Steps M7.2-M7.5 in the process). When the mobile app receives a frame of log sent from the left earpiece, it sets 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 waiting timeout (exceeding the negotiated transmission interval) is reached, the process of requesting the next packet of log data will be triggered.

[0302] M7.6 & M7.7: The mobile app requests the next packet of log data from the left earpiece. The app collected the previous packet of log data through step M7 and recorded the collection details in the corresponding bitmap. Based on the bit values ​​in the bitmap obtained through step M7, the starting offset carried in this request will differ. Specifically:

[0303] If all bits in the bitmap obtained through step M7 above are 1, it means that all log frames sent by the left earpiece during the previous log data request process were received normally without frame loss. The starting offset carried in this request is equal to the starting offset carried in the previous request plus the data size carried in the previous request. The bitmap carried in this request will have all bits set to 0 (indicating that this request is for a new log data packet). The data size carried is consistent with the data size strategy described in step M7 above. When requesting log data that is not the last packet, it is the maximum transmission length allowed for APP requests.

[0304] If the bit values ​​in the bitmap obtained through step M7 above are not all 1, it indicates that there is frame loss. The starting offset carried by this request is equal to the starting offset carried by the previous request. The bitmap carried is the bitmap obtained through step M7 above, indicating that the frame logs in the log data packet of the previous request need to be selectively retransmitted. The data size carried is equal to the data size carried by the previous request.

[0305] After receiving a request from the APP for the next packet of log data, if the left earpiece requests a new packet of log data, it reports the data frame by frame according to step M7 (see steps M7.9-7.12 in Figure 13). If it requests selective retransmission, the left earpiece, based on the bitmap information carried in this request, retransmits the frames with bit values ​​of 0 corresponding to the bits in the bitmap to the APP on the mobile phone (see...). Figure 13a (Steps M7.9-7.12 shown in the diagram);

[0306] Repeat steps M7.6-M7.12 until the compressed log file in the left earphone is successfully reported (i.e., the phone successfully collects the compressed log file from the left earphone).

[0307] M8: The phone requests information for another single file (i.e., the file information of the next log file in the log file list). After the previous log file (the compressed log file xxx_master.zip in the left earpiece) is reported, the app on the phone continues to retrieve the next filename, such as xxx_slave.zip, from the log file list and sends the corresponding file information retrieval request to the left earpiece. After receiving the file information retrieval request, the left earpiece passes it to its WearSDK for parsing;

[0308] M8.1: Confirm whether a master-slave switch is needed. Following step M8.1, the filename specified in the received file information retrieval request contains a "slave" field, indicating that the APP is requesting file information from the compressed log file in the right earpiece. At this point, the WearSDK on the left earpiece, through the master-slave transmission channel established in step D1, informs the right earpiece of the current log reporting status (file information pending reporting status) so that it can be stored in the WearSDK on the right earpiece (corresponding to...). Figure 13b As shown in step M8.2), the WearSDK on the left earphone will also call the interface provided on the main left earphone to inform the left earphone to switch the master and slave device roles (step M8.3). The left earphone will send its pairing information with the mobile phone (communication connection information) to the right earphone through the master and slave transmission channel (step M8.4).

[0309] M'1: The right earphone establishes a connection with the phone. After receiving pairing information from the left earphone and the phone, the right earphone initiates a pairing connection request to the phone and establishes a pairing connection.

[0310] S'1: The left earphone disconnects from the phone. Once the phone establishes a connection with the right earphone, it will disconnect from the left earphone.

[0311] M'2: Prohibit spontaneous master-slave switching between devices. Following steps M'1 and S'1, the right earpiece becomes the new master device and interacts with the phone to report log files, while the left earpiece becomes the slave device (a slave of the right earpiece, connected only to the right earpiece). To prevent further master-slave switching during log reporting interactions between the right earpiece and the phone (transferring the right earpiece's compressed log file xxx_slave.zip), such as spontaneous switching logic caused by changes in the master-slave device's battery level, after the WearSDK on the left earpiece calls its provided interface in step 8.3 to switch master-slave roles, and the right earpiece establishes a connection with the phone, the right earpiece will prohibit spontaneous master-slave switching between devices.

[0312] M'2.2: Successful master / slave device role switch status report. After the right earphone and the mobile phone establish a connection, the current device role status of the right earphone will be reported to its WearSDK. The WearSDK can know whether 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);

[0313] M'3: Log file information reporting. Based on the result of step M'2.2, the right earphone will report information such as the total file size of its compressed log file xxx_slave.zip to the mobile app;

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

[0315] M'5: Log file collection completion stage. After the mobile app completes the collection of compressed log files in the right earpiece, it has completed the collection of all files in the log file list. At this time, the app will inform the right earpiece of the successful collection result (step M'5.1). After the WearSDK on the right earpiece parses the result information, it will inform the right earpiece device side through the interface provided by the log service on the right earpiece (step M'5.2). Once the right earpiece detects that the log file transfer is complete, it will release the restriction on spontaneous master-slave switching between devices.

[0316] In summary, the technical solution provided in this application has the following advantages:

[0317] 1) Introducing a hashing and compression scheme for logs into WearSDK can significantly reduce the size of log files. According to actual tests on a certain product, the log size without hashing was about 13.3M, while the log size after hashing was about 3.78M, a reduction of about 78%. In addition, if the log size was 3.78M before compression, the log size after compression can reach 1.81M, a further reduction of about 47.9%.

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

[0319] 3) A selective retransmission mechanism is introduced into the log reporting process. Based on the bit information recorded in the bitmap, it can be known which log frames were lost in a single request transmission, so that the lost log frames 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 added, and a policy is set that if the number of requests for a packet of log data with the same starting offset exceeds a preset number (such as 3 times), no processing is performed.

[0320] The following embodiments of this application also provide log reporting devices corresponding to the above-described method embodiments. Specifically:

[0321] Figure 14A schematic diagram of a log reporting device according to an embodiment of this application is shown. The device is deployed on a first device, which is a master device that communicates with at least one second device. The first device also communicates with a third device that has log file collection capabilities. See also... Figure 14 The log reporting device provided in this embodiment includes: a generation module 61, a sending module 62, a determining module 63, and an execution module 64. The generation module 61 is used to generate a log file list based on the filenames of a first compressed log file in the first device and the filenames of second compressed log files in the at least one second device when the conditions for reporting log files to the third device are met. The sending module 62 is used to send the log file list to the third device. The determining module 63 is used to determine the filename specified in the request in response to a file information retrieval request sent by the third device based on the log file list. The execution module 64 is used to perform a master-slave switch with the target second device if the specified filename contains the device identifier of the target second device, so that the target second device becomes the master device and communicates with the third device to send the file information of the second compressed log files in the target second device to the third device, so that the third device can perform a packet collection operation of the second compressed log files on the target second device based on the received file information. The target second device is one of the at least one second device.

[0322] Furthermore, when the execution module 64 is used to perform master-slave switching with the target second device, it is specifically used to: send communication connection information between the first device and the third device to the target second device, so that the target second device can establish 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 master-slave switching; and disconnect the communication connection with the third device.

[0323] Furthermore, when the specified filename contains the device identifier of the target second device, the apparatus 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 pending reporting status of the file information of the second compressed log file.

[0324] Furthermore, the aforementioned sending module is also configured to send notifications to the at least one second device respectively, to notify them of the preparation for reporting log files; and the apparatus provided in this embodiment further includes: a compression module, configured to compress multiple log files in the first device together to obtain a first compressed log file; the filename of the first compressed log file contains the device identifier of the first device; a receiving module, configured to receive the filenames of 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 in response to the notification by compressing multiple log files in the second device together; the filename of the second compressed log file contains the device identifier of the second device.

[0325] Furthermore, the apparatus provided in this embodiment further includes: an acquisition module, used to acquire logs generated by an application on the first device; a processing module, used to perform hash processing on the logs generated by the application to obtain the hash-processed logs; and a writing module, used to write the hash-processed logs into the log file corresponding to the application.

[0326] Furthermore, the apparatus provided in this embodiment also includes: a packet splitting module, used to split the first compressed log file into multiple packets of log data, so that the first compressed log file can be subsequently packetized and reported to the third device; wherein, one packet of log data contains multiple log frames.

[0327] Furthermore, the sending module 62 is also configured to send the file information of the first compressed log file to the third device if the specified file name contains the device identifier of the first device, so that the third device can perform a 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: total file size, verification information, which is used by the third device to verify the collected first compressed log file; the log file transmission parameters include at least one of the following: maximum transmission length, frame length of frame log, transmission interval duration, retransmission support; the maximum transmission length is equal to the frame length multiplied by the maximum number of frame log frames that can be continuously transmitted for a single log data acquisition request.

[0328] Furthermore, the retransmission support includes bitmap-based log retransmission; and the 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 starting offset, data size, and frame log bitmap of the requested target packet log data; the frame log bitmap represents a portion of the frame logs in the target packet log data that needs to be retransmitted or represents all the frame logs in the target packet log data that needs to be uploaded; the target packet log data is one packet of log data among the multiple packets of log data included in the first compressed log file; the acquisition module is further configured to, based on the starting offset and the bitmap... The data size is determined by obtaining the target packet log data from the multi-packet log data included in the first compressed log file. The determination module is further configured to determine the frame number of the frame log that needs to be retransmitted based on the frame log bitmap if the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted. The sending module 62 is further configured to selectively retransmit multiple frame logs in the target packet log data to the third device based on the frame number and the negotiated frame length, and is further configured to send multiple frame logs in the target packet log data to the third device frame by frame if the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded.

[0329] Furthermore, the aforementioned determining module 63 is also used to determine the number of times a log data acquisition request carrying the starting offset is received, and when the number is less than or equal to a preset number, to cause the acquisition module to trigger the execution of acquiring the target log data from the multi-packet log data included in the first compressed log file according to the starting offset and the data size.

[0330] Furthermore, the above-mentioned detection of meeting the conditions for reporting log files to the third device includes: receiving a log file list retrieval request sent by the third device; and / or the log files meeting the set requirements; wherein meeting the set requirements includes at least one of the following: reaching the reporting cycle, the number of log files reaching the set number, and the log file storage time reaching the set duration.

[0331] For a detailed description of the functions of each module in the log reporting device provided in this embodiment, please refer to this application. Figure 6 The provided method implementation examples are related to the following content.

[0332] Figure 15 A schematic diagram of a log reporting device according to another embodiment of this application is shown. This device is deployed on a target second device, which 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 master-slave mode. See also... Figure 15The log reporting device provided in this embodiment includes a receiving module 71, a saving module 72, an establishing module 73, and a sending module 74. The receiving module 71 is used to receive a reporting status notification sent by the first device and 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 "file information pending reporting"; 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; and the sending module 74, after establishing a communication connection with the third device, sends 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 a packet collection operation of the second compressed log file on the target second device based on the received file information. The communication connection information is sent by the first device when it performs a master-slave switch with the target second device after determining that the filename 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 based on the received log file list; the log file list is generated by the first device based on the filenames of the first compressed log files in the first device and the filenames of the second compressed log files in 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.

[0333] Furthermore, the device provided in this embodiment also includes: a blocking module, used to prevent the target second device from spontaneously performing master-slave switching after establishing a communication connection with the third device.

[0334] Furthermore, the receiving module 71 is also 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 starting offset, data size, and frame log bitmap of the requested target packet log data; the frame log bitmap indicates whether 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 among the multiple packets of log data included in the second compressed log file; and the device provided in this embodiment further includes: an acquisition module, configured to acquire data based on the starting offset and the data size. The sending module 74 is further configured to: obtain the target packet log data from the multi-packet log data included in the second 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 number 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 number and the negotiated frame length; and if the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded, send the multiple frame logs in the target packet log data frame by frame to the third device.

[0335] Furthermore, the receiving module 71 is also used to release the prohibition on the target second device from spontaneously performing master-slave switching after receiving the notification from the third device that the collection of the second compressed log file is completed.

[0336] Furthermore, 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 a second compressed log file when receiving a log file reporting notification sent by the first device; wherein the file name of the second compressed log file contains the device identifier of the target second device; the aforementioned sending module is further configured to send the file name of the second compressed log file to the first device.

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

[0338] For a detailed description of the functions of each module in the log reporting device provided in this embodiment, please refer to this application. Figure 9 The provided method implementation examples are related to the following content.

[0339] Figure 16A schematic diagram of a log reporting device according to another embodiment of this application is shown, which is deployed on a third device. See also... Figure 16 The log reporting device provided in this embodiment includes: a display module 81, a sending module 82, an establishment / disconnection module 83, a receiving module 84, and an execution module 85. The display module 81 is used to display an interactive interface; the sending module 82 is used to, in response to an operation triggered by a user through the interactive interface, send a log file list retrieval request to the first device selected by the user for log reporting; and the sending module 82 is also used to, based on the log file list received from the first device, send a file information retrieval request to the first device; the establishment / disconnection module 83 is used to, 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; the receiving module 84 is used to receive file information of a second compressed log file in the target second device sent by the target second device; and the execution module 85 is used to, based on the file information of the second compressed log file and log file transmission parameters, execute a request to the target second device... The system is prepared to perform a packet collection operation for the second compressed log file; wherein, the first device is a master device and at least one second device engages in master-slave communication; the log file list is generated by the first device based on the filenames of the first compressed log files in the first device and the filenames 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 device; the target second device sends a communication connection request to the third device based on the communication connection information sent by the first device; the first device sends the communication connection information to the target second device when it determines that the filename specified in the received file information acquisition request contains the device identifier of the target second device and performs a master-slave switch with the target second device.

[0340] Furthermore, the file information of the aforementioned second compressed log file includes: total file size and verification information, which is used by the third device to verify the collected second compressed log file; the log file transmission parameters include: maximum transmission length, frame length of the frame log, transmission interval duration, and retransmission support; the maximum transmission length is equal to the frame length multiplied by the maximum number of frames that can be continuously transmitted in the frame log.

[0341] Furthermore, when the retransmission support is for bitmap-based log retransmission, the execution module 85, when performing packet collection operations of the second compressed log file to the target second device based on the file information and log file transmission parameters of the second compressed log file, specifically performs the following: It sends a log data acquisition request to the target second device based on the file information and log file transmission parameters of the second compressed log file; wherein the parameters carried in this request include: the starting offset of the requested target packet log data, the data size, and the frame log bitmap, wherein the frame log bitmap represents the portion of the frame log in the requested target packet log data that needs to be retransmitted or represents the portion of the frame log that needs to be uploaded. The receiving module 84 is further configured to receive the frame logs sent by the target second device in response to this request, and the apparatus provided in this embodiment further includes: a determining module, configured to determine the frame number of the received frame logs based on the information carried by the received frame logs; a setting module, configured 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 a received value; the determining module is further configured to determine the parameters to be carried in the next request based on the frame log bitmap corresponding to this request when the time is reached to send the next log data acquisition request, until the second compressed log file collection is completed.

[0342] Furthermore, the aforementioned determining module, when determining the parameters to be carried in the next request based on the frame log bitmap corresponding to the current request, specifically performs the following: Based on the frame log bitmap corresponding to the current request, it determines whether there are any frame drops in the target packet log data requested this time; if frame drops exist, the starting offset, data size, and corresponding frame log bitmap of the target packet log data requested this time are respectively determined as the starting offset, data size, and frame log bitmap of the target packet log data to be carried in the next request; if no frame drops exist, the sum of the starting offset and 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 bits in the frame log bitmap to be carried in the next request have values ​​corresponding to "not received," and the data size is the difference between the maximum transmission length or the total file size of the second compressed log file and the size of all received packet log data.

[0343] Furthermore, the timing for sending the next log data acquisition request includes: not receiving a frame log when the waiting time exceeds the transmission interval; and / or the number of received frame logs reaches the maximum number of frames that can be continuously transmitted for a single log data acquisition request.

[0344] For a detailed description of the functions of each module in the log reporting device provided in this embodiment, please refer to this application. Figure 10 The provided method implementation examples are related to the following content.

[0345] Figure 17 A schematic diagram of a log reporting device according to another embodiment of this application is shown, which is deployed on a first device. See also... Figure 17 The log reporting device provided in this embodiment includes: a receiving module 91, an acquisition module 92, and a sending determination module 93. The receiving module 91 is configured to receive a log data acquisition request sent by a third device to a 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 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 that all frame logs in the target packet log data need to be uploaded; the acquisition module 92 is configured to acquire 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; the determining sending module 93 is configured to determine the frame number of the frame logs that need to be retransmitted according to the frame log bitmap if the frame log bitmap indicates that some frame logs in the target packet log data need to be retransmitted; selectively retransmit the multiple frame logs in the target packet log data to the third device according to the frame number and the negotiated frame length; and the determining sending module 93 is further configured to send the multiple frame logs in the target packet log data frame by frame to the third device if the frame log bitmap indicates that all frame logs in the target packet log data need to be uploaded.

[0346] Furthermore, the receiving module 91 is also configured to receive a negotiation request sent by the third device; wherein the negotiation request carries log file transmission parameters. The determining and sending module 93 is also configured to send the negotiation result of the log file transmission parameters to the third device, so that the third device, based on the negotiated log file transmission parameters and the obtained file information of the first compressed log file, sends a log data acquisition request to the first device for the first compressed log file; wherein the log file transmission parameters include at least one of the following: maximum transmission length, frame length of the frame log, transmission interval duration, and retransmission support status; the maximum transmission length is equal to the frame length multiplied by the maximum number of frame log frames that can be continuously transmitted for a single log data request; when the retransmission support status supports bitmap-based log retransmission, the log data acquisition request sent by the third device carries a frame log bitmap.

[0347] For a detailed description of the functions of each module in the log reporting device provided in this embodiment, please refer to this application. Figure 11 The provided method implementation examples are related to the following content.

[0348] Figure 18A schematic diagram of a log reporting device according to another embodiment of this application is shown. This device is deployed on a first device, which establishes a communication connection with a third device, the third device having a log file collection function. See also... 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. Specifically, the acquisition module 1001 acquires logs generated by applications on the first device; the processing module 1002 performs hash processing on the logs generated by the applications to obtain hashed logs; the writing module 1003 writes the hashed logs into the log file corresponding to the application; the compression module 1004 compresses all log files on the first device together to obtain a first compressed log file when the conditions for reporting log files to the third device are met; and the sending module 1005 sends the file information of the first compressed log file to the third device, allowing the third device to perform a packet collection operation on the first device based on the file information.

[0349] Furthermore, the first device also establishes a master-slave communication connection with at least one second device, wherein the first device is the master device in the master-slave communication connection; and the sending module is further configured to send notifications to the at least one second device respectively to notify them to prepare to report log files; the receiving module is further configured to receive the filenames of the second compressed log files sent by the at least one second device respectively; and the apparatus provided in this embodiment further includes: a generation module, configured to generate a log file list based on the filenames of the first compressed log files and the received filenames of the second compressed log files; and the sending module is further configured to send the log file list to the third device; wherein the filename of the first compressed log file contains the device identifier of the first device; the second compressed log file is obtained by the corresponding second device responding to the notification by compressing all its log files together; and the filename of the second compressed log file contains the device identifier of the corresponding second device.

[0350] Furthermore, when the aforementioned sending module is used to send the file information of the first compressed log file to the third device, it is specifically used to: 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; if the specified file name contains the device identifier of the first device, then acquire 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 and verification information, the verification information being used by the third device to verify the collected first compressed log file.

[0351] For a detailed description of the functions of each module in the log reporting device provided in this embodiment, please refer to this application. Figure 12 The provided method implementation examples are related to the following content.

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

[0353] The aforementioned memory 1011 is used to store programs (computer programs) and can be configured to store various other data to support operation on the electronic device. Examples of such data include instructions for any application or method used to operate the electronic device. 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 storage, flash memory, magnetic disk, or optical disk.

[0354] The aforementioned communication module 1013 is configured to facilitate wired or wireless communication between the device housing the communication module and other devices. The device housing the communication module can access wireless networks based on communication standards, such as Bluetooth, WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication module receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication module also includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may 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 used to execute computer programs in the memory.

[0356] See also Figure 19 When the electronic device is a first device 10 or a 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 (hereinafter referred to as log service) is used to manage logs generated by applications on the electronic device, and the management operation includes at least one of the following: hashing the logs, writing the hashed logs into the corresponding log files, and compressing all log files in the electronic device together;

[0357] When the electronic device is a first device, the processor 1012 controls the service component 1014 to execute the program stored in the memory, so that the electronic device can perform the above-mentioned functions. Figure 6 or Figure 11 or Figure 12 The illustrated steps in the log reporting method provided in this application embodiment; 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 above-mentioned... Figure 9 The steps in the log reporting method provided in the embodiments of this application are shown.

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

[0359] Furthermore, such as Figure 19 As shown, when the electronic device is a first device or a second device, the electronic device also includes other components such as a power supply component 1016 and an audio module 1015. Figure 19 Only some components are shown schematically, and it does not mean that the electronic device, when it is the first device or the second device, only includes these components. Figure 19 The components are shown. For a detailed description of the power supply component 1016 and the audio module 1015, please refer to the relevant content in other embodiments below.

[0360] See also Figure 20 When the electronic device is a third device 30, the electronic device also includes a log collection application 1010 (such as...). Figure 20 (The smart space application shown in the figure); wherein, the log collection application communicates with corresponding external devices through the communication component; the processor controls the log collection application to execute the program stored in the memory, so that the electronic device can achieve the above. Figure 10 The steps in the log reporting method provided in the embodiments of this application are shown.

[0361] The aforementioned third device is often a rich device, such as a mobile phone, tablet computer, PDA (Personal Digital Assistant), netbook, desktop computer, virtual reality device (AR / VR device), in-vehicle computer and other electronic devices.

[0362] Furthermore, such as Figure 20 As shown, when the electronic device is a third device, the electronic device also includes other components such as a power supply component 1016 and an audio module 1015. The power supply component 1016 includes a charging management module, a power management module, and a battery. In addition to the above, the electronic device may also include a motor, an indicator, a sensor module, a display screen, a camera, buttons, and external interfaces. Figure 20 The diagram only schematically shows some components of the electronic device and does not imply that the electronic device, when used as a third device, only includes [specific components]. Figure 20 The components shown.

[0363] The motor described above can generate vibration alerts. This could be used for touch-based vibration feedback.

[0364] The aforementioned indicator can be an indicator light used to indicate charging status and power changes, or it can be used to indicate messages, notifications, etc.

[0365] The aforementioned sensor modules may include pressure sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, etc. Among them,

[0366] Pressure sensors are used to sense pressure signals and can convert pressure signals into electrical signals. Examples of pressure sensors include resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors.

[0367] A fingerprint sensor is used to collect fingerprints. Electronic devices can then utilize the characteristics of the collected fingerprints to achieve functions such as fingerprint unlocking.

[0368] Temperature sensors are used to detect temperature. In some embodiments, the electronic device uses the temperature detected by the temperature sensor to execute temperature handling strategies. For example, when the temperature reported by the temperature sensor exceeds a threshold, the electronic device reduces the performance of a processor located near the temperature sensor to reduce power consumption and implement thermal protection. In other embodiments, when the temperature falls below another threshold, the electronic device heats the battery to prevent abnormal shutdown of the electronic device due to low temperature. In still other embodiments, when the temperature falls below yet another threshold, the electronic device boosts the battery's output voltage to prevent abnormal shutdown due to low temperature. Touch sensors, also known as "touch devices," are also used.

[0369] Touch sensors are used to detect touch operations and pass the data to the processor to determine the type of touch event.

[0370] An ambient light sensor is used to detect the brightness of ambient light. Electronic devices can adaptively adjust the brightness of their displays, etc., based on the detected ambient light level.

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

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

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

[0374] The aforementioned buttons include a power button and a keyboard. These buttons can be mechanical or touch-sensitive. The electronic device can receive button input and generate key signal inputs related to user settings and function control.

[0375] The aforementioned memory is internal memory, used to store executable program code, including instructions. The memory may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a given function (such as sound playback, image playback, etc.). The data storage area may store data created during the use of the electronic device (such as audio data, phonebook, etc.). Furthermore, the memory may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory, universal flash storage (UFS), etc. The processor executes various functional applications and data processing of the electronic device by running instructions stored in the memory and / or instructions stored in memory located within the processor.

[0376] The aforementioned external interfaces may include a power interface, a USB interface, a headphone jack, etc.

[0377] The charging management module described above is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module can receive the charging input from the wired charger through an external power interface. In some wireless charging embodiments, 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 power management module described above connects the battery, the charging management module, and the processor. The power management module receives input from the battery and / or the charging management module, supplying power to the processor, internal memory, display screen, camera, and communication module, etc. The power management module can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module may be located within the processor. In still other embodiments, the power management module and the charging management module may be located in the same device.

[0379] Furthermore, another embodiment of this application provides a computer-readable storage medium. This computer-readable storage medium stores a computer program, which, when executed, can perform the steps in the above-described method embodiments.

[0380] Furthermore, this application also provides a computer program product in one embodiment. This computer program product includes a computer program or instructions that, when executed by a processor, cause the processor to perform the steps described in the various method embodiments of this application.

[0381] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this 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 storage, CD-ROM, optical storage, etc.

[0382] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0383] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0384] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

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

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

[0387] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0388] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0389] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A log reporting method, characterized in that, The method is suitable for a first device, the first device is a master device, and the master device communicates with at least one second device in a master-slave mode and also communicates with a third device having a log file collection function; the method comprises the following steps: When it is detected that a condition for reporting a log file to the third device is met, a log file list is generated according to a file name of a first compressed log file in the first device and a file name of a second compressed log file in the at least one second device; The log file list is sent to the third device; In response to a file information acquisition request sent by the third device according to the log file list, a specified file name is determined; If the specified file name contains a device identifier of a target second device, master-slave switching is performed with the target second device, so that the target second device switches to become a master device and communicates with the third device to send file information of the second compressed log file in the target second device to the third device, so that the third device performs a 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 of claim 1, wherein, The master-slave switching with the target second device comprises the following steps: The communication connection information of the first device and the third device is sent 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, the target second device is prohibited from performing master-slave switching voluntarily; The communication connection with the third device is disconnected.

3. The method of claim 1, wherein, When the specified file name contains the device identifier of the target second device, The method further comprises the following steps: A reporting state notification is sent to the target second device to inform the target second device that the current log file reporting state is a file information to be reported state of the second compressed log file.

4. The method according to any one of claims 1 to 3, characterized in that, Before the 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, the method further comprises the following steps: A notification is sent to the at least one second device respectively to notify that log files are ready to be reported; A plurality of log files in the first device are compressed together to obtain the first compressed log file; the file name of the first compressed log file contains a device identifier of the first device; File names of second compressed log files sent by the at least one second device respectively are received; wherein the second compressed log file is obtained by 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 contains a device identifier of the second device.

5. The method of claim 4, wherein, Further comprising the following steps: Obtaining a log generated by an application on the first device; Hash processing the log generated by the application to obtain the log after hash processing; Writing the log after hash processing into a log file corresponding to the application.

6. The method of claim 4, wherein, Further comprising the following steps: The first compressed log file is divided into multiple packet log data, so that the first compressed log file is subsequently packetized and reported to the third device; wherein one packet log data contains multiple frame logs.

7. The method according to any one of claims 1 to 3, characterized in that, Further comprising: If the specified file name contains 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 performs 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 transmission parameters negotiated with the first device; The file information includes: total file size, check information; the check information is used for the third device to check the first compressed log file collected; The log file transmission parameters include at least one of the following: maximum transmission length, frame length of frame log, transmission interval length, retransmission support condition; the maximum transmission length is equal to the frame length multiplied by the maximum number of frame logs that can be continuously transmitted for one log data acquisition request.

8. The method of claim 7, wherein, The retransmission support condition is to support bitmap-based log retransmission; And The method further comprises: 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 starting offset, data size and frame log bitmap of the requested target packet log data; the frame log bitmap represents that part of the frame logs in the target packet log data need to be retransmitted or represents that all the frame logs in the target packet log data need to be uploaded; the target packet log data is one of the multiple packet log data included in the first compressed log file; According to the starting offset and the data size, the target packet log data is acquired from the multiple packet log data included in the first compressed log file; If the frame log bitmap represents that part of the frame logs in the target packet log data need to be retransmitted, the frame number of the frame logs that need to be retransmitted is determined according to the frame log bitmap; according to the frame number and the negotiated frame length, the multiple frame logs in the target packet log data are selectively retransmitted to the third device; If the frame log bitmap represents that all the frame logs in the target packet log data need to be uploaded, the multiple frame logs in the target packet log data are sent to the third device frame by frame.

9. The method of claim 8, wherein, Further comprising: Determine the number of times the log data acquisition request carrying the starting offset is received; When the number of times is less than or equal to a preset number of times, trigger the step of acquiring the target log data from the multiple packet log data included in the first compressed log file according to the starting offset and the data size.

10. The method according to any one of claims 1 to 3, characterized in that, Detecting that the condition for reporting the log file to the third device is 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, and the storage time length of the log file reaching the set time length.

11. A log reporting method, characterized in that, It is suitable for a target second device, which is one of at least one second device; The at least one second device is a slave device in master-slave communication with the first device; and the method comprises: receiving a reporting state notification sent by the first device and communication connection information between the first device and a third device; wherein the reporting state notification is used to inform that the current log file reporting state is a file information to be reported state; saving the current log file reporting state; establishing a communication connection with the third device according to the communication connection information; after the communication connection with the third device is established, sending file information of a second compressed log file in the target second device to the third device according to the saved current log file reporting state, so that the third device performs a packet collection operation on the second compressed log file in the target second device according to the received file information; wherein the communication connection information is sent by the first device when performing master-slave switching with the target second device in the case that the received file information acquisition request specifies a file name with 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 a received log file list; the log file list is generated by the first device according to a file name of a first compressed log file in the first device and a file name of a 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 state of the target second device is switched from a slave device to a master device, and the third device is disconnected from the first device.

12. The method of claim 11, wherein, Further comprising: after the communication connection with the third device is established, prohibiting the target second device from performing master-slave switching spontaneously.

13. The method according to claim 11 or 12, characterized in that, Further comprising: receiving a log data acquisition request sent by the third device for the second compressed log file; wherein the log data acquisition request carries a starting offset, a data size and a frame log bitmap of requested target packet log data; the frame log bitmap represents that part of 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 in multiple packets of log data included in the second compressed log file; acquiring the target packet log data from the multiple packets of log data included in the second compressed log file according to the starting offset and the data size; if the frame log bitmap represents that part of frame logs in the target packet log data need to be retransmitted, determining frame numbers of the frame logs that need to be retransmitted according to the frame log bitmap; and selectively retransmitting multiple frame logs in the target packet log data to the third device according to the frame numbers and a negotiated frame length; if the frame log bitmap represents that all frame logs in the target packet log data need to be uploaded, sending multiple frame logs in the target packet log data to the third device frame by frame.

14. The method of claim 12, wherein, Further comprising: after receiving the second compressed log file collection completion notification sent by the third device, removing the prohibition on the target second device from performing master-slave switching spontaneously.

15. The method of claim 11 or 12, wherein, Further comprising: 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 contains 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 of claim 11 or 12, wherein, Further comprising: Obtain the log generated by the application on the target second device; Hash process the log to obtain the hash processed log; Write the hash processed log into the log file corresponding to the application.

17. A log reporting method, comprising: The method is suitable for a third device, and the method comprises: Display an interactive interface; In response to an operation triggered by a user through the interactive interface, send a log file list acquisition request to the first device selected by the user and needed for log reporting; According to the log file list fed back by the first device, send a file information acquisition request to the first device; 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; 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 log file transmission parameters, perform a packet collection operation of the second compressed log file on the target second device; 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 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 of the third device sent by the first device; the first device sends the communication connection information to the target second device when performing master-slave switching with the target second device under the condition that the file name specified in the received file information acquisition request contains the device identifier of the target second device.

18. The method of claim 17, wherein, The file information of the second compressed log file comprises: total file size and check information; the check information is used for the third device to check the collected second compressed log file; The log file transmission parameters comprise: maximum transmission length, frame length of frame log, transmission interval duration, and retransmission support condition; the maximum transmission length is equal to the frame length multiplied by the maximum number of frame logs that can be continuously transmitted for one log data acquisition request.

19. The method of claim 18, wherein, When the retransmission support condition 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 a packet collection operation of the second compressed log file on the target second device comprises: sending a log data acquisition request to the target second device according to file information and log file transmission parameters of the second compressed log file; wherein, parameters carried in this request include: a starting offset, a data size and a frame log bitmap of target packet log data requested, and the frame log bitmap represents part of frame logs in the target packet log data requested that need to be retransmitted or represents all frame logs in the target packet log data requested that need to be uploaded; receiving frame logs sent by the target second device in response to this request; determining a frame number of the received frame logs according to information carried by the received frame logs; setting a value of a bit corresponding to the frame number of the received frame logs in the frame log bitmap corresponding to this request to a received value; when a timing of sending a next log data acquisition request is reached, determining parameters that need to be carried by the next request according to the frame log bitmap corresponding to this request, until the second compressed log file is collected completely.

20. The method of claim 19, wherein, determining parameters that need to be carried by the next request according to the frame log bitmap corresponding to this request, including: determining whether there is a missing frame in the target packet log data requested according to the frame log bitmap corresponding to this request; when there is a missing frame, setting the starting offset, the data size and the corresponding frame log bitmap of the target packet log data requested in this request as the starting offset, the data size and the frame log bitmap of target packet log data that need to be carried by the next request respectively; when there is no missing frame, setting a sum of the starting offset and the data size of the target packet log data requested in this request as the starting offset of target packet log data that need to be carried by the next request; all bits in the frame log bitmap that need to be carried by the next request correspond to values that are not received, the data size is a maximum transmission length, or a difference between a total file size of the second compressed log file and a size of all packet log data that has been received.

21. The method of claim 19, wherein, the timing of sending a next log data acquisition request is reached, including: not receiving frame logs when a waiting time length exceeds a transmission interval length; and / or a number of received frame logs reaches a maximum number of frames that can be continuously transmitted for one log data acquisition request.

22. A log reporting method, comprising: The method is suitable for a first device, and the method includes: receiving 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 a starting offset, a data size and a frame log bitmap of target packet log data requested; the frame log bitmap represents part of frame logs in the target packet log data that need to be retransmitted or represents all frame logs in the target packet log data that need to be uploaded; acquiring the target packet log data from multiple packet log data included in the first compressed log file according to the starting offset and the data size; when the frame log bitmap represents part of frame logs in the target packet log data that need to be retransmitted, determining frame numbers of frame logs that need to be retransmitted according to the frame log bitmap; and selectively retransmitting multiple frame logs in the target packet log data to the third device according to the frame numbers and a negotiated frame length. If the frame log bitmap represents that all frame logs in the target package log data need to be uploaded, the multiple frame logs in the target package log data are sent to the third device frame by frame.

23. The method of claim 22, wherein, Further comprising: Receiving the negotiation request sent by the third device; wherein the negotiation request carries log file transmission parameters; Sending the negotiation result of the log file transmission 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 transmission parameters and the file information of the first compressed log file obtained; Wherein, the log file transmission parameters include at least one of the following: maximum transmission length, frame length of frame log, transmission interval time, retransmission support; the maximum transmission length is equal to the frame length multiplied by the maximum number of frames that can be continuously transmitted for a log data request; when the retransmission support is to support bitmap-based log retransmission, the log data acquisition request sent by the third device carries a frame log bitmap.

24. A log reporting method, comprising: Suitable for the first device, the first device and the third device have a communication connection, and the third device has a log file collection function; the method comprises: Obtaining the log generated by the application on the first device; Hash processing the log generated by the application to obtain the hash processed log; Write the hash processed log into the log file corresponding to the application; When it is detected that the conditions for reporting the log file to the third device are met, compress all log files in the first device to obtain a first compressed log file; Send the file information of the first compressed log file to the third device, so that the third device performs the package collection operation of the first compressed log file on the first device according to the file information.

25. The method of claim 24, wherein, The first device also has a master-slave communication connection with at least one second device, and the first device is the master in the master-slave communication connection; And the method further comprises: Send a notification to the at least one second device respectively to notify the preparation of reporting log files; Receive the file name of the second compressed log file sent by the at least one second device respectively; According to the file name of the first compressed log file and the file name of the second compressed log file received, generate a log file list; Send the log file list to the third device; Wherein, the file name of the first compressed log file contains the device identifier of the first device; the second compressed log file is obtained by compressing all log files in the corresponding second device in response to the notification; the file name of the second compressed log file contains the device identifier of the corresponding second device.

26. The method of claim 25, wherein, Send the file information of the first compressed log file to the third device, including: 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; If the file name contains the device identifier of the first device, the file information of the first compressed log file is acquired, and the file information of the first compressed log file is sent to the third device; The file information of the first compressed log file includes total file size and check information, and the check information is used for the third device to check the first compressed log file collected.

27. A log reporting system, characterized by The system comprises: The third device has a log file collection function; At least one second device; The first device is in communication connection with the third device and in master-slave communication connection with the at least one second device, and the first device is the master in the master-slave communication connection, 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 log files to the third device is met, and sending the log file list to the third device; The third device is used for taking one file name from the log file list and generating a file information acquisition request according to the taken file name, and sending the file information acquisition request to the first device; The first device is further used for determining the specified file name in response to the file information acquisition request, and performing master-slave switching with the target second device if the specified file name contains the device identifier of the target second device, so that the target second device switches to become the master device and communicates with the third device to 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 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 by The system comprises: The third device has a log file collection function; The first device is in communication connection with the third device and is used 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 starting offset, data size and frame log bit map of the requested target packet log data; the frame log bit map represents part of the frame log in the target packet log data that needs to be retransmitted or represents all the frame log in the target packet log data that needs to be uploaded; the target packet log data is acquired from the multiple packet log data included in the first compressed log file according to the starting offset and the data size; if the frame log bit map represents part of the frame log in the target packet log data that needs to be retransmitted, the frame number of the frame log that needs to be retransmitted is determined according to the frame log bit map; multiple frame logs in the target packet log data are selectively retransmitted to the third device according to the frame number and the negotiated frame length; if the frame log bit map represents all the frame log in the target packet log data that needs to be uploaded, the multiple frame logs in the target packet log data are sent to the third device frame by frame.

29. An electronic device, comprising: The electronic device is a first device, a second device, or a third device; the electronic device comprises a memory, a processor, and a communication component; the memory is configured to store a program; the processor is coupled to the memory; When the electronic device is the first device or the second device, the electronic device further comprises a service component comprising a log service module; the service component communicates with a corresponding external device through the communication component; the log service module is configured to manage logs generated by applications on the electronic device, and the management comprises at least one of the following: performing hash processing on the logs, writing the logs after the hash processing into corresponding log files, and compressing all log files in the electronic device together; 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 of any one of claims 1 to 10, or implements the steps in the log reporting method of any one of claims 22 or 23, or implements the steps in the log reporting method of any one of claims 24 to 26; 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 of any one of claims 11 to 16; When the electronic device is the third device, the electronic device further comprises 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 of any one of claims 17 to 21.

Images