Log capture method, electronic device and computer readable storage medium

Abstract

The present application relates to the field of software technology, and more particularly to a log capture method, electronic device, and computer-readable storage medium. In this method, since applications (applications, APPs) corresponding to smart headphones and smart watches can usually be installed on devices such as smart phones and smart tablets, for example, sports health APPs corresponding to smart watches can be installed on smart phones. Therefore, when smart phones and smart tablets capture their own log data, log capture instructions can be sent to the corresponding APPs of smart headphones and smart watches, so that when devices such as smart headphones and smart watches work together with devices such as smart phones and smart tablets and fail, the corresponding APPs installed on smart phones and smart tablets can capture the log data of devices such as smart headphones and smart watches at the same time, so as to jointly analyze the log data of these devices and determine the problem.

Description

Technical Field

[0001] The present application relates to the field of software technology, and in particular to a log capture method, an electronic device, and a computer-readable storage medium. Background Art

[0002] When a problem occurs in a multi-device collaboration scenario, it is often necessary to jointly analyze the log data of multiple devices in the collaborative scenario to determine the problem. For example, in a collaborative scenario where a user wears a smart headset to watch a video on a smartphone, if the picture displayed on the smartphone is not synchronized with the sound played by the smart headset, it is necessary to jointly analyze the logs of the smartphone and the smart headset to determine the problem.

[0003] Therefore, a method is needed to simultaneously capture log data of multiple devices when a problem occurs in a multi-device collaboration scenario. Summary of the invention

[0004] The present application provides a log capture method, an electronic device, and a computer-readable storage medium. In this method, since applications (applications, APPs) corresponding to smart headphones and smart watches can usually be installed on devices such as smart phones and smart tablets, for example, a sports health APP corresponding to a smart watch can be installed on a smart phone. Therefore, when a smart phone or smart tablet captures its own log data, a log capture instruction can be sent to the corresponding APP of the smart headphones and smart watches, so that when devices such as smart headphones and smart watches work together with devices such as smart phones and smart tablets and a fault problem occurs, the log data of devices such as smart headphones and smart watches can be captured simultaneously through the corresponding APP installed on the smart phone and smart tablet, so as to jointly analyze the log data of these devices and determine the problem.

[0005] In a first aspect, the present application provides a log capture method, which includes: a first electronic device performs business communication with a second electronic device; the first electronic device detects a first fault event during the business communication process and generates first log data, and the first electronic device obtains second log data generated by the second electronic device through a first application, wherein the first application is installed on the first electronic device and corresponds to the second electronic device, and the first log data and the second log data include log data related to the first fault event.

[0006] In some implementations, the first electronic device is a rich device such as a smart phone, a tablet computer, etc. The second electronic device is a thin device such as a smart headset, a smart bracelet, a smart watch, etc. The difference between a rich device and a thin device is that a rich device has sufficient space resources and computing power resources to capture log data and analyze the log data, while a thin device has fewer space resources and computing power resources than a rich device and cannot analyze the log data.

[0007] In some implementations, business communication refers to the collaborative work between a first electronic device (such as a smart phone) and a second electronic device (such as a smart headset), or the collaborative work between the first electronic device, the second electronic device and other electronic devices. For example, a smart phone and a smart headset collaboratively play a video, wherein the video image is displayed on the smart phone, and the sound of the video is played on the smart headset.

[0008] In some implementations, the first failure event refers to an event in which the inter-device collaboration cannot be smoothly performed due to a problem with any electronic device during the above-mentioned service communication process. Figure 1b In the case of a problem with the smartphone or smart headset, the sound and picture of the smartphone and the smart headset are out of sync.

[0009] In some implementations, the first application is an application installed on the first electronic device and corresponding to the second electronic device, for example, a sports health application installed on a smart phone and corresponding to a smart bracelet or a smart watch.

[0010] Through the above method, when the first electronic device detects the occurrence of a fault event, the first electronic device can obtain the first log data generated by itself and obtain the second log data of the second electronic device through the first application corresponding to the second electronic device, so as to jointly analyze these log data and determine the problem.

[0011] In combination with the first aspect, in a possible implementation of the first aspect, the first electronic device also performs business communications with a third electronic device, and the method also includes: the first electronic device sends a first instruction to the third electronic device, the first instruction includes the number of the first log data, and the first instruction is used to instruct the third electronic device to obtain third log data with the same number as the first log data, and the third log data is generated by the third electronic device.

[0012] In some implementations, the third electronic device and the first electronic device are both rich devices. Business communication between the first electronic device and the third electronic device and the second electronic device means that when the first electronic device and the second electronic device work together, the first electronic device is also communicatively connected to the third electronic device. It can be understood that since the first electronic device, the second electronic device and the third electronic device are all in the same collaborative working scenario, when the first electronic device obtains the first log data and the second log data, it also needs to obtain the third log data of the third electronic device for the same fault event, so as to jointly analyze the three log data and determine the problem.

[0013] In combination with the first aspect and the above-mentioned possible implementation methods, in a possible implementation method of the first aspect, a first electronic device displays a first interface, the first interface includes a first control, the first control is used to determine whether a first fault event occurs, and the first electronic device detects the first fault event during business communication, including: the first electronic device detects that the first control is triggered, and determines that the first fault event is detected.

[0014] That is, the first electronic device can determine that the first fault event is detected when it detects that the first control is triggered. In some implementations, the first control can be triggered when the user perceives that the device has a fault in a collaborative work scenario. For example, the first control can be triggered when the user finds that the health information about the user on the smart bracelet and the smart phone is not synchronized (such as the number of steps the user walks is not synchronized). For another example, the first control can be triggered when the user finds that the sound and picture of the smart phone and the smart headset are not synchronized. This application does not limit this.

[0015] In combination with the first aspect and the above-mentioned possible implementations, in a possible implementation of the first aspect, the first interface is an interface of a first application. That is, the first interface may be an interface of a first application corresponding to the second electronic device, for example, the first interface may be an interface of a sports health corresponding to a smart bracelet installed on a smart phone. In this way, the user can trigger the first control when any fault event is found (not limited to a fault event found when the first electronic device and the second electronic device perform a certain function).

[0016] In combination with the first aspect and the above possible implementations, in a possible implementation of the first aspect, the first interface is an interface of a second application different from the first application, and the first fault event includes a fault event of the second application. That is, the first interface may be an interface with other applications installed on the first electronic device, for example, the first interface may be an interface of a video application installed on a smartphone (see below). Figure 5). In this way, when the first electronic device and the second electronic device cooperate to perform a certain function, the user can trigger the first control more timely, so that the first electronic device can capture the log data of the two devices corresponding to the fault event more timely.

[0017] In combination with the first aspect and the above-mentioned possible implementation methods, in a possible implementation method of the first aspect, the first electronic device detecting a first fault event during business communication also includes: the type of the fault event detected by the first electronic device is a preset type, and it is determined that the first fault event is detected.

[0018] That is, in some implementations, the first fault event may be a certain type of pre-set fault event, so that when this type of fault event occurs, the first electronic device can automatically detect the occurrence of the fault event according to the type of the fault event, and automatically obtain the above-mentioned first log data and second log data.

[0019] In combination with the first aspect and the above possible implementations, in a possible implementation of the first aspect, the first electronic device also performs business communication with a fourth electronic device, and the method further includes: the first electronic device sends a second instruction to the fourth electronic device, the second instruction includes the fault type of the first fault event, and the second instruction is used to instruct the fourth electronic device to obtain fourth log data with the same fault type as the first fault event, and the fourth log data is generated by the fourth electronic device. The fourth electronic device is similar to the above third electronic device.

[0020] That is, since the type of the first fault event is determined, when the first electronic device controls the fourth electronic device to obtain the fourth log data generated by the fourth electronic device and corresponding to the first fault event, it only needs to send the type of the fault event to the fourth electronic device, so that the fourth electronic device can also obtain the log data corresponding to the type of fault event according to the type of the fault event.

[0021] In combination with the first aspect and the above possible implementations, in a possible implementation of the first aspect, the second instruction is further used to instruct the fourth electronic device to send fourth log data to the cloud server. That is, the fourth electronic device can upload the fourth log data to the cloud server to facilitate the cloud server to perform big data analysis based on the log data.

[0022] In combination with the first aspect and the above possible implementations, in a possible implementation of the first aspect, the method further includes: the first electronic device sends the first log data and the second log data to the cloud server. That is, the first electronic device can upload the first log data and the second log data to the cloud server, so that the cloud server can perform big data analysis based on the log data.

[0023] In combination with the first aspect and the above possible implementations, in a possible implementation of the first aspect, the first instruction is further used to instruct the third electronic device to send third log data to the cloud server. That is, the third electronic device can upload the third log data to the cloud server to facilitate the cloud server to perform big data analysis based on the log data.

[0024] In combination with the first aspect and the above-mentioned possible implementation methods, in a possible implementation method of the first aspect, the first electronic device is arranged with a software system architecture, the software system architecture includes a first application layer, the first application layer includes a log capture module, the first electronic device detects a first fault event during a business communication process, including: the first electronic device detects the first fault event during the business communication process through the log capture module; and the first electronic device obtains second log data generated by the second electronic device through the first application, including: the first electronic device sends a third instruction to the second electronic device through the log capture module, and the third instruction is used to instruct the second electronic device to send the second log data to the first electronic device.

[0025] In combination with the first aspect and the foregoing possible implementations, in a possible implementation of the first aspect, the first electronic device sends first log data to a cloud server through a log capture module.

[0026] In combination with the first aspect and the above-mentioned possible implementation methods, in a possible implementation method of the first aspect, the first application is arranged in a first application layer, the first application layer also includes a sending module corresponding to the first application, and the first electronic device sends the second log data to the cloud server through the sending module.

[0027] In combination with the first aspect and the above-mentioned possible implementation methods, in a possible implementation method of the first aspect, the electronic device is arranged with a software system architecture, the software system architecture includes a first application layer, the first application layer also includes a message transmission module, and the first electronic device sends a first instruction to a third electronic device, including: the first electronic device sends the first instruction to the third electronic device through the message transmission module.

[0028] In combination with the first aspect and the above-mentioned possible implementation methods, in a possible implementation method of the first aspect, the first electronic device is arranged with a software system architecture, the software system architecture includes a first application layer, the first application layer includes a fault engine, and the first electronic device detects a first fault event during business communication, including: the first electronic device determines through the fault engine that the type of the detected fault event is a preset type, and determines that the first fault event is detected.

[0029] In combination with the first aspect and the foregoing possible implementations, in a possible implementation of the first aspect, the first electronic device sends first log data to a cloud server through a fault engine.

[0030] In combination with the first aspect and the above-mentioned possible implementation methods, in a possible implementation method of the first aspect, the first electronic device includes a mobile phone, and the second electronic device includes at least a smart bracelet, a smart headset or a smart watch.

[0031] In combination with the first aspect and the foregoing possible implementation manners, in a possible implementation manner of the first aspect, the third electronic device includes a tablet computer.

[0032] In a second aspect, an embodiment of the present application further provides an electronic device, comprising a memory storing computer program instructions; and a processor, wherein the processor and the memory are coupled, and when the computer program instructions stored in the memory are executed by the processor, the electronic device implements the above-mentioned first aspect and any one of the possible implementation methods of the first aspect.

[0033] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program, characterized in that when the computer program is executed by a processor, it implements the above-mentioned first aspect and a method of any one of any possible implementation methods of the first aspect.

[0034] In a fourth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes the method of any one of the first aspect and any possible implementation manner of the first aspect.

[0035] It can be understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1a According to the implementation of the present application, a schematic diagram of a scenario in which a smart headset and a smart phone work together is shown, wherein 01 is a smart phone and 02 is a smart headset;

[0037] Figure 1b According to the implementation of the present application, a schematic diagram showing the asynchronism of sound and picture that occurs when a smart phone and a smart headset work together is shown;

[0038] Figure 2 According to the implementation of the present application, a schematic diagram of the system structure is shown in which the rich device 01 simultaneously captures its own log data and the log data of the thin device 02 in a collaborative work scenario;

[0039] Figure 3According to the implementation of this application, a schematic diagram of the system structure of rich device 01, thin device 02 and other rich devices capturing logs corresponding to fault events in a collaborative work scenario is shown;

[0040] Figure 4 According to the implementation method of this application, it is shown Figure 3 Schematic diagram of the interaction flow of each device in the software system structure;

[0041] Figure 5 According to the implementation of the present application, a schematic diagram of an interface in which a command to grab log data is detected on a rich device 01 is shown;

[0042] Figure 6 According to the implementation of the present application, another schematic diagram of the system structure is shown in which the rich device 01 simultaneously captures its own log data and the log data of the thin device 02 in a collaborative work scenario;

[0043] Figure 7 According to the implementation of the present application, a schematic diagram of the system structure of rich device 01, thin device 02 and other rich devices capturing logs corresponding to fault events in a collaborative work scenario is shown;

[0044] Figure 8 According to the implementation method of this application, it is shown Figure 7 Schematic diagram of the interaction flow of each device in the software system structure;

[0045] Fig. 9 A schematic diagram of the hardware structure of a mobile phone is shown according to the implementation method of the present application. DETAILED DESCRIPTION

[0046] The present application provides a log capture method, an electronic device, and a computer-readable storage medium. The following will use terms commonly used by those skilled in the art to describe various aspects of the illustrative embodiments. Among them, in the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A or B exists at the same time, and B exists alone. In addition, in the description of the implementation of the present application, "multiple" refers to two or more than two.

[0047] In the following, the terms "first", "second", and "third" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first", "second", and "third" may explicitly or implicitly include one or more of the features.

[0048] The log capture method provided in each embodiment of the present application can be applied in a multi-device collaboration scenario including one or more terminal devices such as smart phones, tablet computers, wearable devices, vehicle-mounted devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), etc.

[0049] Figure 1a The following is a schematic diagram showing a scenario to which the method of this application is applicable. Figure 1a As shown, device 01 and device 02 of user 00 work together. User 00 watches a video through device 01 and listens to the video playback sound through device 02 at the same time. In some implementations of the present application, device 01 includes but is not limited to a smartphone, a tablet computer, a car device, and the like. Device 02 includes but is not limited to a smart headset, a smart watch, and the like. For ease of description, the following description uses a smartphone as device 01 and a smart headset as device 02. Figure 1b Shows Figure 1a In the scenario shown, when user 00 watches video 10 through mobile phone 01, the video playback progress is "01:01" and the corresponding subtitles are "abcd", but the subtitles heard by user 00 through headphones 02 are "efgh", that is, the picture played by user 00's mobile phone 01 does not match the text heard by headphones 02.

[0050] In this case, the log data of mobile phone 01 and headset 02 need to be jointly analyzed to determine the problem.

[0051] In order to achieve the above purpose, the present application provides a log capture method. In the log capture method of the present application, since applications (applications, APPs) corresponding to smart headphones and smart watches can usually be installed on devices such as smart phones and smart tablets, for example, sports health APPs corresponding to smart watches can be installed on smart phones. Therefore, when smart phones and smart tablets capture their own log data, log capture instructions can be sent to the corresponding APPs of smart headphones and smart watches, so that when devices such as smart headphones and smart watches work together with devices such as smart phones and smart tablets and fail, the corresponding APPs installed on smart phones and smart tablets can capture the log data of devices such as smart headphones and smart watches at the same time, so as to jointly analyze the log data of these devices and determine the problem.

[0052] The following is combined with Figures 2 to 8The implementation process of this application is specifically introduced. For the convenience of description, smart phones, tablet computers, etc. are collectively referred to as rich devices, and smart headphones, smart watches, etc. are collectively referred to as thin devices.

[0053] Figure 2 According to an embodiment of the present application, a schematic block diagram of a system structure for simultaneously capturing logs of a rich device 01 and a thin device 02 in a scenario where the rich device 01 and the thin device 02 work in collaboration is shown.

[0054] like Figure 2 As shown, the system includes a rich device 01 , a thin device 02 and a cloud server 03 .

[0055] The application layer 010 of the rich device 01 includes a log capture module 011, which is used to capture log data of the rich device 01 when an instruction to capture logs is detected. In some implementations, the log capture module 011 may be a HiView service, which is not limited in this application.

[0056] In some implementations, the log capture module 011 is further used to package the log data after capturing the log data of the rich device 01, and upload the packaged log data compression package to the cloud server 03. In some implementations, after the log capture module 011 obtains the log data and packages and compresses the log data, the packaged log data can be uploaded to the cloud through a log upload channel (such as hiview tunnel), and this application does not limit this.

[0057] In some implementations, detecting the instruction to capture the log includes detecting that the corresponding control is triggered, or detecting that a specific type of fault event occurs when the rich device 01 and the thin device 02 work together. The specific type of fault event can be preset by the R&D personnel. For example, the fault event of the sound and picture being out of sync when the headset 02 and the mobile phone 01 work together can be set as a fault event with a fault event number of "95011254", which is not limited in this application.

[0058] In some implementations, the log capture module 0110 is further used to send a first instruction to the thin device APP when an instruction to capture logs is detected or a specific type of failure event is detected during collaborative work, and the first instruction is used to control the thin device APP to obtain the log data of the thin device 02 corresponding to the rich device 01. In some implementations, the log capture module 011 will at least obtain the number (ID) of the log data when capturing the log.

[0059] In some implementations, the application layer 011 also includes a thin device APP 012. In some implementations, the thin device APP includes but is not limited to a smart space APP corresponding to a smart headset, and a sports health APP corresponding to a smart watch or a smart bracelet.

[0060] In some implementations, the thin device APP 012 includes a sending module 012a and a receiving module 012b. The receiving module 012b is used to receive the first instruction of the log capture module 011, and capture the log data of the thin device 02 under the control of the first instruction. The sending module 012b is used to package and upload the log data sent by the thin device 02 to the cloud server 03 after receiving the log data.

[0061] In some implementations, the rich device 01 determines that the first instruction is detected after detecting that the corresponding control is triggered. Figure 4 introduce.

[0062] In some implementations, the thin device 02 includes but is not limited to the above-mentioned smart watches, smart bracelets, smart headphones and other devices.

[0063] In some implementations, the application layer 020 of the thin device 02 includes an instruction parsing module 021, a collection module 022, and a return module 023. The instruction parsing module 021 is used to parse the instruction for obtaining logs sent by the thin device APP 012 installed on the rich device 01, and then forward the parsed instruction to the collection module 022 to control the collection module 022 to obtain the log data of the thin device 02. In some implementations, the instruction parsing module 021 and the collection module 022 can also be combined into one module, and accordingly, the module can implement both the functions of the instruction parsing module 021 and the functions of the collection module 022.

[0064] In some implementations, the feedback module 023 is used to transmit the log data of the thin device back to the thin device APP 012 of the rich device 01 after the collection module 022 obtains the log data of the thin device, so that the thin device APP 012 can package the log data and upload it to the cloud server 03.

[0065] In some implementations, the return module 023 and the collection module 022 may be combined into one module, and the combined module may implement both the functions of the return module and the functions of the collection module 022. This application does not limit this.

[0066] In some implementations, the cloud server 03 is used to receive and store the log data obtained by the rich device 01 and the thin device 02, and analyze the log data to determine the problem. In some implementations, after determining the problem that occurred in the device during the collaborative work, the cloud server 03 can store the device number corresponding to the device and the type of fault event and fault type together, so that other users can also use the data stored in the cloud server 03 for analysis.

[0067] It is understandable that it is not just one thin device that works with the rich device. For example, the mobile phone 01 may be connected to the headset 02 and the tablet computer 01′ to work together. In this case, the tablet computer 01′ will also obtain its own log data and upload the log data to the cloud server 03.

[0068] Specifically, Figure 3 According to an embodiment of the present application, a schematic diagram of a scenario in which log data of a rich device 01, a rich device 01' and a thin device 02 are simultaneously acquired when the rich device 01, a rich device 01' and a thin device 02 work in collaboration is shown.

[0069] in, Figure 3 and Figure 2 The difference is Figure 3 Also connected to the rich device 01 is a rich device 01′. When the rich device 01 detects an instruction to obtain log data or detects a specific type of fault event, the rich device 01 obtains the log data through the log capture module 011. In some implementations, the rich device 01 sends the ID corresponding to the log data to be obtained to the rich device 01′ through the message transmission module 011a of the log capture module 011 and the message transmission module 011a′ of the rich device 01′, triggering the rich device 01′ to also obtain the log data with the same ID on it.

[0070] In some implementations, the rich device 01′ packages the acquired log data through the log capture module 011′ and uploads it to the cloud server 03. That is, when the collaborative work scenario includes more than one rich device, when one of the rich devices (such as the rich device 01) acquires log data, it will not only acquire the log data of the thin device 01 through the thin device APP 010 installed thereon, but also control another rich device to acquire the log data of the same ID through the message transmission module of the log capture module.

[0071] Figure 3Taking the example of rich device 01 obtaining log data and controlling rich device 01′ to obtain log data through message passing module 011a of log capture module 011 to message passing module 011a′ of log capture module 011′ of rich device 01 as an example, it can be understood that obtaining log data by rich device 01′ and controlling rich device 01 to obtain log data through message passing module 011a′ of its log capture module 011′ and message passing module 011a of log capture module 011 of rich device 01 are the same.

[0072] Furthermore, it can be understood that if a thin device APP is also installed on the rich device 01′, the rich device 01′ can also obtain the log data of the thin device 02 through the thin device APP. This process is the same as the rich device 01 obtaining the log data of the thin device 02 through the thin device APP.

[0073] In some implementations, the software structure layer of each device in the above-mentioned rich device 01, rich device 01' and thin device 02 includes but is not limited to the application layer, and may also include the hardware layer, physical layer, application framework layer, etc., which is not limited in this application.

[0074] Figure 4 According to the embodiment of the present application, Figure 3 Schematic diagram of the interaction flow between the various software modules of the various devices involved in the process. Specifically, Figure 4 As shown, the process includes:

[0075] 401 , the log capture module 011 of the rich device 01 receives a first instruction.

[0076] In some implementations, the first instruction is an instruction detected by the rich device 01 that a corresponding control on the rich device 01 is triggered. Figure 5 According to the implementation of the present application, a schematic diagram of an interface for detecting a first instruction when the mobile phone 01 and the headset 02 have a problem of out-of-sync audio and video is shown.

[0077] like Figure 5 As shown, the mobile phone 01 detects a preset gesture and displays an interface 102. In some implementations, the preset gesture includes but is not limited to double-click, single-click, long press, short press, etc., and this application does not limit this. In some implementations, the interface 102 includes a playback speed option a, a playback error option b, and a playback effect option c. After the mobile phone 01 detects that the playback error option b is triggered, it determines that the first instruction is detected.

[0078] In some implementations, it is understandable that the first instruction may also be sent to the rich device 01 by the remote diagnosis platform, and this application does not impose any limitation on this.

[0079] 402 , the log capture module 011 of the rich device 01 sends an instruction to capture log data to the thin device APP 012 .

[0080] 403 , the thin device APP 012 of the rich device 01 sends an instruction to capture log data to the instruction parsing module 021 of the thin device 02 .

[0081] 404, the instruction parsing module 021 of the thin device 02 parses the received instruction.

[0082] It can be understood that when the rich device 01 works in cooperation with the thin device 02, it will send various instructions to the thin device 02, such as instructions for starting the thin device 02, instructions for data transmission with the thin device 02, etc. Therefore, in the implementation of the present application, the instruction summary module 021 of the thin device 01 needs to parse the received instructions and determine that the received instructions are instructions for capturing log data.

[0083] 405 , the instruction parsing module 021 of the thin device 02 sends an instruction to the collection module 022 to capture log data.

[0084] 406, the collection module 022 of the thin device 02 captures the log data of the thin device 02.

[0085] It can be understood that the instruction to capture log data is sent by the rich device 01 to the thin device 02 when the rich device 01 receives the first instruction, and the first instruction is triggered when the user determines that a problem occurs in the collaborative work scenario. Figure 5 Therefore, the log data of the thin device 02 captured by the collection module 022 of the thin device 02 at this time is also related to the problem occurred in the collaborative work scenario.

[0086] 407 , the collection module 022 of the thin device 02 sends the log data of the thin device 02 to the return module 023 .

[0087] 408 , the feedback module 023 of the thin device 02 returns the log data to the thin device APP 012 of the rich device 01 .

[0088] 409 , the thin device APP 012 of the rich device 01 uploads the log data to the cloud server 03 .

[0089] 410 , the log capture module 011 of the rich device 01 obtains the log data of the rich device 01 .

[0090] In some implementations, the log capture module 011 of the rich device 01 may obtain the log data of the rich device 01 at the same time as the rich device 01 obtains the log data of the thin device 02 through the thin device APP 012 .

[0091] 411 , the log capture module 011 of the rich device 01 compresses and packages the acquired log data of the rich device 01 .

[0092] 412, the log capture module 011 of the rich device 01 sends the packaged log data to the log upload channel 011c.

[0093] 413 , the log upload channel 011 c of the rich device 01 uploads the packaged log data to the cloud server 03 .

[0094] 414 , the log capture module 011 of the rich device 01 sends the acquired log data number of the rich device 01 to the message transmission module 011 a .

[0095] In some implementations, since the rich device 01′ will also generate corresponding log data when a problem occurs in collaborative work, and since the log data are all generated for the same fault event, the number or ID number of the log data generated by the rich device 01′ and the rich device 01 for the fault event is the same. Therefore, the rich device 01 can send the number of the log data it obtains to the rich device 01′, so that the rich device 01′ can also obtain the corresponding log data according to the number of the log data.

[0096] 415 , the message transfer module 011 a of the rich device 01 sends the serial number of the log data of the rich device 01 to the message transfer module 011 a ′ of the rich device 01 ′.

[0097] 416 , the message transmission module 011 a ′ of the rich device 01 ′ sends the serial number of the log data of the rich device 01 to the log capture module 011 ′.

[0098] 417 , the log capture module 011 ′ of the rich device 01 ′ obtains the number of the log data of the rich device 01 ′ which is the same as the number of the log data of the rich device 01 .

[0099] 418 , the log capture module 011 ′ of the rich device 01 ′ compresses and packages the acquired log data of the rich device 01 ′.

[0100] 419, the log capture module 011' of the rich device 01' sends the packaged log data to the log delivery channel 011c'.

[0101] 420 , the log delivery channel 011 c ′ of the rich device 01 ′ uploads the packaged log data to the cloud server 03 .

[0102] Through the above method, when problems arise when multiple devices are working together, log data generated by multiple devices in the collaborative work scenario for the same problem or the same fault event can be obtained at the same time, so as to jointly analyze these log data and determine where the problem lies, that is, which device failure caused the problem in the collaborative work.

[0103] Furthermore, it can be seen that, through the above method, the log data of other devices in the collaborative work scenario can be obtained through only one device (for example, the above-mentioned rich device 01), and since the first instruction received by the above-mentioned rich device 01 is received when the user determines that a problem occurs in the collaborative work, it can also be ensured that the log data of each device obtained are related to the problem that occurs in the collaborative work, thereby ensuring the efficiency of obtaining log data and the accuracy and timeliness of the log data.

[0104] Figure 6 According to an embodiment of the present application, another schematic block diagram of a system structure for simultaneously capturing logs of a rich device 01 and a thin device 02 in a scenario where a rich device 01 and a thin device 02 work together is shown. Figure 2 The same parts can be referred to the above description, and will not be repeated here. Figure 2 , Figure 6 The difference is that the application layer 010 of the rich device 01 also includes a fault engine 011b, and Figure 6 In the embodiment, after the fault engine 011b of the rich device 01 detects a specific type of fault event, it sends an instruction to the log capture module 011 to capture the log data of the thin device 02, and the log capture module 011 captures the log data of the thin device 02 through the thin device APP 012. In addition, in some implementations, after the fault engine 011b detects a specific type of fault event, it will also capture the log data of the rich device 01. In some implementations, after obtaining the log data, the fault engine 011b of the rich device 01 will also package the log data and upload it to the cloud server 03. In some implementations, the fault engine 011b can upload the log data to the cloud server 03 through the log upload channel 011c. This application does not limit this.

[0105] Similarly, Figure 7 According to an embodiment of the present application, another system structure schematic block diagram is shown for simultaneously capturing logs of rich device 01, rich device 01' and thin device 02 in a scenario where rich device 01, rich device 01' and thin device 02 work in collaboration.

[0106] based on Figure 6 , Figure 7After the fault engine 011b detects a specific type of fault event, the fault engine 011b obtains the log data of the rich device 01 and packages the log data and uploads it to the cloud server 03.

[0107] In some implementations, since there are multiple rich devices working in cooperation with the thin device 02, the fault engine 011b will also obtain the ID of the rich device associated with the thin device 02 or the rich device 01 (eg Figure 7 In some implementations, the fault engine 011b sends the acquired ID of the associated device and the specific type of fault event to the message delivery module 011a, and the message delivery module 011a sends the specific type of fault event to the message delivery module of the associated device corresponding to the associated device ID (e.g. Figure 7 The message transmission module 011a' of the rich device 01' associated with the rich device 01 in the message transmission module 011a' is then sent by the message transmission module 011a' to the fault engine 011b' of the rich device 01', so that the fault engine 011b' of the rich device 01' obtains the log data corresponding to the fault event of the specific type on the rich device 01'. In some implementations, the fault engine 011b' packages the obtained log data corresponding to the fault event of the specific type and uploads the log data to the cloud server 03.

[0108] In some implementations, the software structure layer of each device in the above-mentioned rich device 01, rich device 01' and thin device 02 includes but is not limited to the application layer, and may also include the hardware layer, physical layer, application framework layer, etc., which is not limited in this application.

[0109] Figure 8 According to the embodiment of the present application, Figure 7 A schematic diagram of the interaction flow between the software modules of each device involved in the process. Figure 8 Zhongyu Figure 4 The same parts can refer to the above description, and will not be repeated here. Figure 8 As shown, the process includes:

[0110] 801, the fault engine 011b of the rich device 01 detects a fault event of a specific type.

[0111] In some implementations, developers can set different types of fault events that may occur during collaborative work in advance. For example, developers can set the black screen event of a thin device APP on a smartphone (such as a sports health APP on a smartphone) during collaborative work to "95011256". Then, when a black screen event occurs in the sports health APP on the smartphone, the fault engine on the smartphone can detect a fault event of type "95011256". This application does not limit this.

[0112] It can be understood that after the fault engine 011b of the rich device 01 detects a certain type of fault event, it can determine that this type of fault event occurs in a collaborative work scenario, and further obtain log data of each device involved in the collaborative work scenario to analyze the cause of the fault event.

[0113] 802, the fault engine 011b of the rich device 01 sends an instruction to capture log data to the log capture module 011 of the rich device 01. Since the rich device 01 needs to send an instruction to capture log data to the thin device APP 021 through the log capture module 011, in the implementation of the present application, the fault engine 011b of the rich device 01 needs to send an instruction to capture log data to the log capture module 011.

[0114] 803 , the fault engine 011 b of the rich device 01 sends an instruction to capture log data to the thin device APP 021 of the rich device 01 .

[0115] 804 , the thin device APP 012 of the rich device 01 sends an instruction to capture log data to the instruction parsing module 021 of the thin device 02 .

[0116] 805, the instruction parsing module 021 of the thin device 02 parses the received instruction.

[0117] 806 , the instruction parsing module 021 of the thin device 02 sends an instruction to the collection module 022 to capture log data.

[0118] 807, the collection module 022 of the thin device 02 captures the log data of the thin device 02.

[0119] 808 , the collection module 022 of the thin device 02 sends the log data of the thin device 02 to the sending module 023 .

[0120] 809 , the sending module 023 of the thin device 02 returns the log data to the thin device APP 012 of the rich device 01 .

[0121] 810 , the thin device APP 012 of the rich device 01 uploads the log data to the cloud server 03 .

[0122] 811 , the fault engine 011 b of the rich device 01 obtains the log data of the rich device 01 .

[0123] In some implementations, the fault engine 011b of the rich device 01 may obtain the log data of the rich device 01 synchronously with the rich device 01 obtaining the log data of the thin device 02 through the log capture module 011 and the thin device APP 012, and this application does not impose any limitation on this.

[0124] 812 , the fault engine 011b of the rich device 01 compresses and packages the obtained log data of the rich device 01 .

[0125] 813, the fault engine 011b of the rich device 01 sends the packaged and compressed log data to the log transmission channel 011c.

[0126] 814 , the log transmission channel 011 c of the rich device 01 uploads the packaged and compressed log data to the cloud server 03 .

[0127] 815, the fault engine 011b of the rich device 01 obtains the ID of the associated device.

[0128] It is understandable that there may be multiple rich devices working in cooperation with the thin device 02, and in the implementation of the present application, the method of detecting a specific type of fault event by the fault detector 011b is a passive fault detection method, which is different from Figure 4 In the method of actively triggering the capture of logs by the user, in some implementation methods of the present application, when the fault engine 011b of the rich device 01 obtains the log data of the thin device 01 and other rich devices, the fault engine 011b of the rich device 01 can also simultaneously obtain the ID of the device associated with the thin device 01, so as to subsequently upload the ID of these associated devices and the log data of the above-mentioned specific type of fault events corresponding to the associated devices to the cloud server 3 for big data analysis.

[0129] In some implementations, the fault engine 011b of the rich device 01 can obtain the IDs of other rich devices that work in cooperation with the rich device 01 through the communication module of the rich device 01. It can be understood that obtaining the IDs of other devices associated with a device through a certain device is a technology known to those skilled in the art, and this application does not limit this.

[0130] 816 , the fault engine 011 b of the rich device 01 sends the ID of the associated device and the fault event of the specific type to the message delivery module 011 a .

[0131] 817 , the message transfer module 011 a of the rich device 01 sends the specific type of fault event to the message transfer module 011 a ′ of the rich device 01 ′.

[0132] It can be understood that since the fault engine 011b of the rich device 01 has sent the ID of the associated device to the message transmission module 011a, in the implementation of the present application, the message transmission module 011a can determine the corresponding rich device 01′ based on the associated device ID, and then send the above-mentioned specific type of fault event to the rich device 01′ corresponding to the associated device ID.

[0133] 818 , the message transfer module 011 a ′ of the rich device 01 ′ sends a specific type of fault event to the fault engine 011 b ′.

[0134] It can be understood that since the log data of the rich device 01′ needs to be obtained by its fault engine 011b′, after the message transmission module 011a′ of the rich device 01′ obtains a specific type of fault event, it also sends the specific type of fault event to the fault engine 011b′, so that the fault engine 011b′ can obtain the log data corresponding to the rich device 01′ and the specific type of fault event.

[0135] 819 , the fault engine 011 b ′ of the rich device 01 ′ obtains log data corresponding to a specific type of fault event.

[0136] 820 , the fault engine 011 b ′ of the rich device 01 ′ packages and compresses the log data.

[0137] 821, the fault engine 011b' of the rich device 01' sends the packaged and compressed data to the log transmission channel 011c'.

[0138] 822 , the log transmission channel 011 c ′ of the rich device 01 ′ uploads the packaged and compressed data to the cloud server 03 .

[0139] Through the above method, rich devices (such as smart phones), etc., can automatically detect a specific type of fault event when it occurs, and then automatically trigger the log capture instruction to capture related log data, so that after a specific type of fault event occurs, the rich device can also simultaneously obtain the log data on the thin device and other rich devices corresponding to the specific type of fault event.

[0140] Fig. 9 According to an embodiment of the present application, a schematic diagram of the hardware structure of a rich device is shown.

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

[0142] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the rich device 100. In other embodiments of the present application, the rich device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0143] The processor 110 may include one or more processing units, for example: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and / or a neural-network processing unit (neural-network processing unit, NPU), etc. Among them, different processing units can be independent devices or integrated in one or more processors. Among them, the controller can be the nerve center and command center of the rich device 100. The controller can generate an operation control signal according to the instruction opcode and the timing signal to complete the control of fetching and executing instructions.

[0144] A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. Repeated access is avoided, the waiting time of the processor 110 is reduced, and the efficiency of the system is improved. In some implementations, the processor 110 may be used to execute the above methods 401 to 420 and 801 to 820.

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

[0146] Among them, the I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). The I2S interface can be used for audio communication. The PCM interface can also be used for audio communication to sample, quantize and encode analog signals. The UART interface is a universal serial data bus used for asynchronous communication. The bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication.

[0147] The MIPI interface can be used to connect the processor 110 with peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), etc. In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to implement the shooting function of the rich device 100. The processor 110 and the display screen 194 communicate via the DSI interface to implement the display function of the rich device 100.

[0148] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present application is only for illustrative purposes and does not constitute a structural limitation on the rich device 100. In other embodiments of the present application, the rich device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0149] The charging management module 140 is used to receive charging input from the charger. The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The wireless communication function of the rich device 100 can be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor. The mobile communication module 150 can provide solutions for wireless communication including 2G / 3G / 4G / 5G applied to the rich device 100. The wireless communication module 160 can provide solutions for wireless communication including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) network), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication technology (NFC), infrared technology (IR) and the like applied to the rich device 100.

[0150] The rich device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

[0151] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), MiniLed, MicroLed, Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the rich device 100 may include 1 or N display screens 194, where N is a positive integer greater than 1. In some implementations of the present application, the display screen 194 is used to display the above Figure 1b , Figure 5 The human-computer interaction interface shown.

[0152] The rich device 100 can implement a shooting function through an ISP, a camera 193, a video codec, a GPU, a display screen 194, and an application processor.

[0153] ISP is used to process the data fed back by camera 193. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to ISP for processing and converts it into an image visible to the naked eye. ISP can also perform algorithm optimization on the noise, brightness, and skin color of the image. ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, ISP can be set in camera 193.

[0154] The camera 193 is used to capture static images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element may be In some embodiments, the rich device 100 may include 1 or N cameras 193, where N is a positive integer greater than 1.

[0155] The digital signal processor is used to process digital signals, and can process not only digital image signals but also other digital signals. For example, when the rich device 100 is selecting a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy.

[0156] Video codecs are used to compress or decompress digital videos. Rich device 100 may support one or more video codecs. In this way, rich device 100 can play or record videos in multiple coding formats, such as moving picture experts group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0157] NPU is a neural network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can also continuously self-learn. Through NPU, applications such as intelligent cognition of the rich device 100 can be realized, such as: image recognition, face recognition, voice recognition, text understanding, etc.

[0158] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the rich device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

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

[0160] The rich device 100 can implement audio functions such as music playing and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0161] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be arranged in the processor 110, or some functional modules of the audio module 170 can be arranged in the processor 110.

[0162] The speaker 170A, also called a "speaker", is used to convert an audio electrical signal into a sound signal. The rich device 100 can listen to music or listen to a hands-free call through the speaker 170A.

[0163] The receiver 170B, also called a "handset", is used to convert audio electrical signals into sound signals. When the rich device 100 receives a call or voice message, the voice can be heard by placing the receiver 170B close to the ear.

[0164] Microphone 170C, also called "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or sending a voice message, the user can speak by putting their mouth close to microphone 170C to input the sound signal into microphone 170C. The rich device 100 can be provided with at least one microphone 170C. In other embodiments, the rich device 100 can be provided with two microphones 170C, which can not only collect sound signals but also realize noise reduction function. In other embodiments, the rich device 100 can also be provided with three, four or more microphones 170C to realize the collection of sound signals, noise reduction, identification of sound sources, realization of directional recording function, etc.

[0165] The earphone interface 170D is used to connect a wired earphone and can be a USB interface 130 or a 3.5 mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0166] The pressure sensor 180A is used to sense the pressure signal and convert the pressure signal into an electrical signal. The gyroscope sensor 180B can be used to determine the motion posture of the rich device 100. The air pressure sensor 180C is used to measure the air pressure. In some embodiments, the rich device 100 calculates the altitude through the air pressure value measured by the air pressure sensor 180C to assist in positioning and navigation. The magnetic sensor 180D includes a Hall sensor. The acceleration sensor 180E can detect the magnitude of the acceleration of the rich device 100 in various directions (generally three axes). When the rich device 100 is stationary, the magnitude and direction of gravity can be detected. It can also be used to identify the posture of the electronic device, and is applied to horizontal and vertical screen switching, pedometers and other applications. The distance sensor 180F is used to measure the distance. The rich device 100 can measure the distance through infrared or laser. The proximity light sensor 180G may include, for example, a light emitting diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode. The ambient light sensor 180L is used to sense the ambient light brightness. The rich device 100 can adaptively adjust the brightness of the display screen 194 according to the perceived ambient light brightness. The fingerprint sensor 180H is used to collect fingerprints. The rich device 100 can use the collected fingerprint characteristics to realize fingerprint unlocking, access application locks, fingerprint photography, fingerprint answering calls, etc. The temperature sensor 180J is used to detect temperature. In some embodiments, the rich device 100 uses the temperature detected by the temperature sensor 180J to execute a temperature processing strategy. The touch sensor 180K is also called a "touch panel". The touch sensor 180K can be set on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, also called a "touch screen". The bone conduction sensor 180M can obtain vibration signals. The button 190 includes a power button, a volume button, etc. The button 190 can be a mechanical button. It can also be a touch button. The rich device 100 can receive key input and generate key signal input related to the user settings and function control of the rich device 100. The motor 191 can generate a vibration prompt. The motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. The indicator 192 may be an indicator light, which may be used to indicate the charging status, power change, messages, missed calls, notifications, etc. The SIM card interface 195 is used to connect a SIM card.

[0167] The above describes the possible hardware structure of the rich device 100. It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the rich device 100. In other embodiments of the present application, the rich device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0168] An embodiment of the present application also provides an electronic device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on at least one processor, wherein when the processor executes the computer program, the steps in any of the above-mentioned method embodiments are implemented.

[0169] The embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0170] An embodiment of the present application provides a computer program product. When the computer program product runs on a mobile terminal, the mobile terminal can implement the steps in the above-mentioned method embodiments when executing the computer program product.

[0171] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device that can carry the computer program code to the camera / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a disk or an optical disk.

[0172] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A log capture method, characterized in that: include: The first electronic device performs business communication with the second electronic device, wherein: The space resources and computing power resources of the second electronic device are smaller than those of the first electronic device, and the second electronic device does not have a function of analyzing log data. The first electronic device includes at least one of the following devices: a smart phone, a tablet computer; The second electronic device includes at least one of the following devices: a smart headset, a smart bracelet, and a smart watch; During the service communication, the first electronic device and the second electronic device play the first video in collaboration, the first electronic device plays the picture of the first video, and the second electronic device plays the sound of the first video; The first electronic device detects a first fault event during the service communication, wherein the first fault event is used to indicate that the picture of the first video played by the first electronic device and the sound of the first video played by the second electronic device are out of sync; The first electronic device captures first log data generated by the first electronic device through a log capture module and uploads the first log data to a cloud server, and the first electronic device sends a first instruction to a receiving module of a first application through the log capture module, wherein the first application is installed on the first electronic device and corresponds to the second electronic device; The receiving module sends a log acquisition instruction to the instruction parsing module of the second electronic device in response to the first instruction; The instruction parsing module parses the instruction for obtaining the log, and forwards the parsed instruction to the collection module of the second electronic device, The collection module acquires second log data generated by the second electronic device in response to the parsed instruction, wherein the first log data and the second log data include log data related to the first fault event; The collection module sends the second log data to the return module of the second electronic device; The feedback module returns the received second log data to the sending module of the first application program; The sending module uploads the received second log data to the cloud server; The first electronic device jointly analyzes the first log data and the second log data to determine a faulty device causing the first fault event.

2. The method according to claim 1, characterized in that The first electronic device also performs service communication with a third electronic device, and the method further includes: The first electronic device sends a first instruction to the third electronic device, the first instruction including the number of the first log data, and the first instruction is used to instruct the third electronic device to obtain third log data with the same number as the first log data, and the third log data is generated by the third electronic device.

3. The method according to claim 1, characterized in that The first electronic device displays a first interface, the first interface includes a first control, the first control is used to determine whether the first fault event occurs, and the first electronic device detects the first fault event during the service communication process, including: The first electronic device detects that the first control is triggered and determines that the first fault event is detected.

4. The method according to claim 3, characterized in that The first interface is an interface of the first application.

5. The method according to claim 3, characterized in that: The first interface is an interface of a second application program different from the first application program, and the first failure event includes a failure event of the second application program.

6. The method according to claim 1, characterized in that The first electronic device detecting a first failure event during the service communication process further includes: The type of the fault event detected by the first electronic device is a preset type, and it is determined that a first fault event is detected.

7. The method according to claim 6, characterized in that The first electronic device also performs service communication with a fourth electronic device, and the method further includes: The first electronic device sends a second instruction to the fourth electronic device, the second instruction including the fault type of the first fault event, and the second instruction is used to instruct the fourth electronic device to obtain fourth log data with the same fault type as the first fault event, and the fourth log data is generated by the fourth electronic device.

8. The method according to claim 7, characterized in that The second instruction is also used to instruct the fourth electronic device to send the fourth log data to the cloud server.

9. The method according to claim 1, characterized in that: The method further comprises: The first electronic device sends the first log data and the second log data to a cloud server.

10. The method according to claim 2, characterized in that The first instruction is also used to instruct the third electronic device to send the third log data to the cloud server.

11. The method according to claim 1, characterized in that: The first electronic device is arranged with a software system architecture, the software system architecture includes a first application layer, the first application layer includes a log capture module, and the first electronic device detects a first fault event during the service communication process, including: The first electronic device detects a first fault event during the service communication process through the log capture module; and The first electronic device obtaining, through the first application, second log data generated by the second electronic device, includes: The first electronic device sends a third instruction to the second electronic device through the log capture module, and the third instruction is used to instruct the second electronic device to send the second log data to the first electronic device.

12. The method according to claim 11, characterized in that The first electronic device sends the first log data to the cloud server through the log capture module.

13. The method according to claim 11, characterized in that The first application is arranged in the first application layer, and the first application layer also includes a sending module corresponding to the first application, and the first electronic device sends the second log data to the cloud server through the sending module.

14. The method according to claim 2, characterized in that The electronic device is arranged with a software system architecture, the software system architecture includes a first application layer, the first application layer also includes a message transmission module, and the first electronic device sends the first instruction to the third electronic device, including: The first electronic device sends a first instruction to the third electronic device through the message transmission module.

15. The method according to claim 6, characterized in that The first electronic device is arranged with a software system architecture, the software system architecture includes a first application layer, the first application layer includes a fault engine, and the first electronic device detects a first fault event during the service communication process, including: The first electronic device determines, through the fault engine, that the type of the detected fault event is a preset type, and determines that a first fault event is detected.

16. The method according to claim 15, characterized in that The first electronic device sends the first log data to a cloud server through the fault engine.

17. The method according to claim 1, characterized in that The first electronic device includes a mobile phone, and the second electronic device includes at least a smart bracelet, a smart headset or a smart watch.

18. The method according to claim 2, characterized in that The third electronic device includes a tablet computer.

19. A computer readable medium, characterized in that The computer-readable medium stores instructions, which, when executed on a computer, cause the computer to perform the method according to any one of claims 1 to 18.

20. An electronic device, characterized in that: The electronic device comprises: a memory for storing instructions to be executed by one or more processors of the electronic device, and One or more processors, configured to execute instructions stored in the memory, so that the electronic device performs the method as claimed in any one of claims 1 to 18.

21. A computer program product, characterized in that When the computer program product runs on an electronic device, the electronic device is caused to execute the method according to any one of claims 1 to 18.

Images