CN116049112A - 多设备日志上报的方法和系统 - Google Patents

Abstract

本申请提供一种多设备日志上报的方法和系统，方法应用于第一设备，第一设备和第二设备通信连接，方法包括：基于通信连接的功能出现故障后，第一设备采集第一日志数据，第一日志数据为第一设备的日志数据；第一设备向云端上报第一日志数据；第一设备向第二设备发送通知消息，以触发第二设备向云端上报第二日志数据，第二日志数据为第二设备的日志数据。基于通信连接的功能出现故障后，通过第一设备触发第二设备，可以使第一设备和第二设备及时上报日志数据，提高了相互连接的多个电子设备向云端上传日志数据的效率。

Description

多设备日志上报的方法和系统

技术领域

本申请涉及日志上报技术领域，尤其涉及一种多设备日志上报的方法和系统。

背景技术

部分电子设备具有和附近的其他电子设备互联的功能，多台具有互联功能的电子设备可以通过蓝牙、无线局域网(WiFi)等通信技术建立连接以传输数据。例如，手机和大屏设备互联后，手机屏幕的画面通过大屏设备展示；手机和智能手环互联后，智能手环可以用于接打电话。

多设备互联时若发生故障，为了定位并处理故障，互联的多个设备均需要向采用应用程序虚拟化技术的软件平台(例如云端)上报设备的日志数据。现有技术中，互联的多个设备会分别独立上传自身的日志数据，效率较低，不利于云端快速获得互联的多个设备的日志数据。

发明内容

针对上述问题，本申请提供了一种多设备日志上报的方法和系统，以实现互联的多个电子设备同步上报日志数据，提高多设备互联时上报日志数据的效率。

为了实现上述目的，本申请提供了以下技术方案：

本申请第一方面提供一种多设备日志上报的方法，应用于第一设备，所述第一设备和第二设备通信连接，所述方法包括：

基于所述通信连接的功能出现故障后，所述第一设备采集第一日志数据，所述第一日志数据为所述第一设备的日志数据；

所述第一设备向云端上报所述第一日志数据；

上述步骤可以参见图7所示的实施例中的步骤S701，或者图8所示的实施例中的步骤S801，或者图10所示的实施例中的步骤S1001；

所述第一设备向所述第二设备发送通知消息，以触发所述第二设备向云端上报第二日志数据，所述第二日志数据为所述第二设备的日志数据。

上述步骤可以参见图7所示的实施例中步骤S702和S703，或者图8所示的实施例中的步骤S802和S803，或者图10所示的实施例中的步骤S1002和S1003。

在一个示例中，参见图4所示的实施例，上述第一设备可以是图4所示的手机100，第二设备可以是图4所示的电脑300，相应的，第一日志数据可以是手机100的日志数据，第二日志数据可以是电脑300的日志数据，通知消息可以是图4对应的步骤A12中手机100向电脑300发送的特性码和标识符。

在另一个示例中，参见图6所示的实施例，上述第一设备可以是图6所示的电脑300，第二设备可以是图6所示的手机100，相应的，第一日志数据可以是电脑300的日志数据，第二日志数据可以是手机100的日志数据。

在一些可选的实施例中，还包括：

所述第一设备向第三设备发送数据采集命令，所述第一设备和所述第三设备通信连接，所述第三设备不具有联网能力；

上述步骤可以参见图7所示的实施例中的步骤S704，或者图10所示的实施例中的步骤S1004；

所述第一设备接收所述第三设备反馈的第三日志数据，所述第三日志数据为所述第三设备的日志数据；

上述步骤可以参见图7所示的实施例中的步骤S705，或者图10所示的实施例中的步骤S1005；

所述第一设备向云端上报所述第三日志数据。

上述步骤可以参见图7所示的实施例中的步骤S706，或者图10所示的实施例中的步骤S1006。

在一个示例中，参见图4或图9，第三设备可以是手环200，也可以是其他不具有联网能力的瘦设备，如蓝牙耳机等。

在一些可选的实施例中，所述通知消息包括所述第一设备确定的用于标记所述故障的标识符；

所述第一设备向云端上报所述第一日志数据，包括：

所述第一设备向云端上报所述第一日志数据和所述标识符；

所述第二设备向云端上报第二日志数据，包括：

所述第二设备向云端上报第二日志数据和所述标识符。

参见图4所示的实施例，所述第一设备向云端上报所述第一日志数据和所述标识符相当于图4的步骤A9，即手机100的上传模块将标识符和手机的日志数据打包上传给云端；所述第二设备向云端上报第二日志数据和所述标识符，相当于图4所示实施例的步骤A16，即电脑300的上传模块将标识符和电脑的日志数据打包上传给云端。

将日志数据和标识符一并上传的效果在于，便于云端根据标识符将第一设备的日志数据和第二设备的日志数据相关联。

在一些可选的实施例中，还包括：

所述第一设备响应于上报操作，确定特性码；

所述第一设备采集第一日志数据，包括：

所述第一设备根据所述特性码采集所述日志数据；

所述通知消息包括所述特性码。

上述步骤可以参见图4对应实施例的步骤A7和A8，以及图6对应实施例的步骤B1。

参见图5，使用者执行上报操作前，第一设备的采集应用可以显示如图5所示的界面，第一设备根据使用者在图5所示的界面上的选项，确定特性码。

在一些可选的实施例中，所述第一设备采集第一日志数据，包括：

所述第一设备响应于预设的故障检测代码产生的故障码，根据所述故障码采集所述第一日志数据；

所述通知消息包括所述故障码。

本实施例中，故障检测代码预先设置于第一设备所安装的应用程序中，若应用程序运行时出现故障，其中设置的故障检测代码就会检测到故障并输出预设的故障码。

上述步骤可以参见图9对应的实施例的步骤C1和C2。

在一些可选的实施例中，所述第一设备向云端上报所述第一日志数据，包括：

所述第一设备向云端上报所述第一日志数据和所述第一设备的本地码；

所述第二设备向云端上报第二日志数据，包括：

所述第二设备向云端上报第二日志数据和所述第二设备的本地码；

所述第二设备的本地码和云端记录的所述第一设备的远程码相同。

参见图9对应的实施例，第一设备的本地码可以是图9对应的实施例中的手机本地码，第二设备的本地码可以是图9对应的实施例中的电脑本地码，第一设备的远程码可以是图9对应的实施例中的手机远程码。

将第一设备的本地码和第二设备的本地码与日志数据一并上传的作用在于，便于云端根据各设备的本地码和云端预先记录的远程码将第一设备的日志数据和第二设备的日志数据相关联。

本申请第二方面提供一种多设备日志上报的方法，其特征在于，应用于第二设备，所述第二设备和第一设备通信连接，所述方法包括：

所述第二设备响应于所述第一设备的通知消息，采集第二日志数据，所述第二日志数据为所述第二设备的日志数据；

上述步骤可以参见图7所示的实施例中的步骤S702，或者图8所示的实施例中的步骤S802，或者图10所示的实施例中的步骤S1002；

所述第二设备向云端上报所述第二日志数据。

上述步骤可以参见图7所示的实施例中的步骤S703，或者图8所示的实施例中的步骤S803，或者图10所示的实施例中的步骤S1003。

在一些可选的实施例中，还包括：

所述第二设备向第四设备发送数据采集命令，所述第二设备和所述第四设备通信连接，所述第四设备不具有联网能力；

示例性的，第四设备可以是图6对应的实施例的手环200，上述步骤相当于图8对应实施例的步骤S804；

所述第二设备接收所述第四设备反馈的第四日志数据，所述第四日志数据为所述第四设备的日志数据；

示例性的，上述步骤相当于图8对应实施例的步骤S805；

所述第二设备向云端上报所述第四日志数据。

示例性的，上述步骤相当于图8对应实施例的步骤S806。

在一些可选的实施例中，所述通知消息包括所述第一设备确定的特性码；

所述第二设备响应于所述第一设备的通知消息，采集第二日志数据，包括：

所述第二设备响应于所述第一设备的通知消息，根据所述通知消息中的特性码采集第二日志数据。

上述步骤可以参见图4对应的实施例的步骤A15，或者参见图6对应的实施例的步骤B8。

本申请第三方面提供一种多设备日志上报的系统，包括第一设备，第二设备和云端，所述第一设备和所述第二设备通信连接；

基于所述通信连接的功能出现故障后，所述第一设备用于向所述云端上报第一日志数据，所述第一日志数据为所述第一设备的日志数据；

所述第二设备用于被所述第一设备触发后，向所述云端上报第二日志数据，所述第二日志数据为所述第二设备的日志数据；

所述云端用于展示所述第一日志数据和所述第二日志数据。

本申请提供一种多设备日志上报的方法和系统，方法应用于第一设备，第一设备和第二设备通信连接，方法包括：基于通信连接的功能出现故障后，第一设备采集第一日志数据，第一日志数据为第一设备的日志数据；第一设备向云端上报第一日志数据；第一设备向第二设备发送通知消息，以触发第二设备向云端上报第二日志数据，第二日志数据为第二设备的日志数据。基于通信连接的功能出现故障后，通过第一设备触发第二设备，可以使第一设备和第二设备及时上报日志数据，提高了相互连接的多个电子设备向云端上传日志数据的效率。

附图说明

图1为本申请实施例提供的一种多设备互联的场景示意图；

图2为本申请实施例提供的另一种多设备互联的场景示意图；

图3为本申请实施例提供的一种电子设备的软件框架示意图；

图4为本申请实施例提供的一种互联的多设备上报日志时的数据交互示意图；

图5为本申请实施例提供的一种手动触发上报日志的界面示意图；

图6为本申请实施例提供的另一种互联的多设备上报日志时的数据交互示意图；

图7为本申请实施例提供的一种多设备日志上报的方法的时序图；

图8为本申请实施例提供的另一种多设备日志上报的方法的时序图；

图9为本申请实施例提供的再一种互联的多设备上报日志时的数据交互示意图；

图10为本申请实施例提供的再一种多设备日志上报的方法的时序图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形式，除非其上下文中明确地有相反指示。还应当理解，在本申请实施例中，“一个或多个”是指一个、两个或两个以上；“和/或”，描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

多设备互联，是指，多个电子设备之间通过蓝牙、无线局域网(WiFi)等通信技术建立通信连接，并基于建立的通信连接实现多个电子设备之间数据共享的功能。

请参见图1，为本申请提供的一种多设备互联的场景示意图。在图1所示的场景中，手机100同时和手环200，以及电脑300建立连接，当手机100被呼叫时，与手机100连接的手环200和电脑300均可以产生相应的提示，并且用户可以在手环200或电脑300上接听手机100的呼叫。

请参见图2，为本申请提供的另一种多设备互联的场景示意图。手机100和智慧屏400建立连接后，手机100可以基于通信连接向智慧屏400发送图像数据，从而将手机100屏幕的画面在智慧屏400上显示，完成投屏。

在多设备互联时，若当前的服务异常中断，相互连接的各个电子设备均需要向云端上报自身的日志数据，以便根据各个电子设备的日志数据确定导致异常中断的故障发生在哪个电子设备上以及故障的具体信息。

以图1所示的场景为例，手机100被呼叫时，两个用户分别在手环200和电脑300接听呼叫，一段时间后通话异常中断，此时手机100，手环200和电脑300都需要向云端上传自身的日志数据。

目前，多个电子设备均需要上报日志数据时，通常需要用户或技术人员分别在每个电子设备上执行上报操作才能触发该电子设备上报日志数据，也就是说，在图1所示的场景中，用户或技术人员需要逐一触发手机100，手环200和电脑300上报日志数据。

为了提高多设备互联的场景中相互连接的多个电子设备上报日志数据的效率，本申请提供一种多设备日志上报的方法。

可以理解，相互连接的多个电子设备所运行的系统可以相同也可以不相同，本实施例对此不作限定。示例性的，在图1所示的场景中，手机100运行安卓(Android)操作系统，电脑300运行Windows操作系统，在图2所示的场景中，手机100和智慧屏400均运行安卓操作系统。

本申请实施例以分层架构的Android系统为例，示例性说明用于执行本申请的多设备日志上报的方法的手机100的软件结构。

图3是本申请实施例的手机100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Androidruntime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。如图3所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

例如，在本申请实施例中，应用程序层可以包括连接应用和采集应用。连接应用可以用于和蓝牙耳机、智能手环等电子设备建立蓝牙连接，并在建立蓝牙连接后管理这些电子设备。

蓝牙耳机和智能手环等电子设备主要通过蓝牙和其他电子设备连接，内存较小且不能直接接入局域网或移动蜂窝网络(即不具有联网能力)。在一些可选的实施例中，可以将具有上述特征的电子设备(包括但不限于蓝牙耳机、智能手环、蓝牙音箱)统称为瘦设备；相对的，手机、电脑等内存较大，具有多种功能，能够接入局域网和/或移动蜂窝网络(即具有联网能力)的电子设备可以统称为富设备。

采集应用，用于向用户或技术人员提供上报日志数据的操作接口。当发现电子设备存在异常(例如图1中接通的通话异常中断)时，用户或技术人员可以通过采集应用提供的界面执行上报操作，然后采集应用可以响应用户的操作而触发电子设备的其他模块或组件，使电子设备采集并向云端上报日志数据。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。如图3所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。本实施例中，应用程序框架层还可以包括采集模块和上传模块。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供手机100的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

采集模块，用于采集电子设备的日志数据。

上传模块，用于将采集模块采集到的日志数据打包，然后将打包得到的包含日志数据的压缩包向云端上传。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。本实施例中，系统库还可以包括互助采集模块和消息通道组件。

互助采集模块，用于向上层(包括应用程序层和应用程序框架层)提供访问消息通道组件所需的接口。例如，应用程序框架层的采集模块通过互助采集模块和系统库的消息通道组件交互。

消息通道组件，用于提供短程通信技术解决方案，简化蓝牙和wifi的连接，使用户能够简单地交换信息、访问内容与服务；多个电子设备的消息通道组件可以基于预先配置的私有通信协议进行通信，从而在多个电子设备之间建立图1所示的通信连接。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

需要说明，尽管以手机100为例，但图3所示的软件结构并不仅限于手机，任意一个运行安卓操作系统的电子设备(如安卓系统的平板电脑，智慧屏)均可以具有图3所示的软件结构。

下面结合图3所示的软件结构，进一步说明本申请提供的多设备日志上报的方法。

需要说明，本申请所提供的多设备日志上报的方法，可以适用于测试场景下的被测电子设备；也可以适用于日常使用场景下普通用户使用的用户电子设备。

其中，适用于用户电子设备时，用户电子设备可以在采集日志数据之前显示确认提示窗口，确认提示窗口用于提示用户确认是否开放日志采集权限，若用户确认开放日志采集权限，用户电子设备采集日志数据并上报，若用户确认不开放日志采集权限，则用户电子设备不采集日志数据，相应的也不执行本申请提供的方法。

在一些实施例中，用户电子设备可以在每次采集日志数据之前均显示确认提示窗口，也可以仅在开机后首次需要采集日志数据时显示一次确认提示窗口，此后根据首次显示确认提示窗口时用户的选择决定是否采集日志数据。

在一些实施例中，用户电子设备也可以提示用户是否加入测试计划，若用户确认加入测试计划，则默认开放日志采集权限，若用户确认不加入测试计划，则默认不开放日志采集权限。

实施例一

本实施例中，电子设备上报日志数据的行为由使用者(用户或技术人员)手动触发。

下面结合图1所述的场景说明本申请提供的多设备日志上报的方法中的数据交互，请参见图4，为本实施例提供的互联的多设备上报日志时的数据交互示意图。

手机100，手环200和电脑300相互建立通信连接，其中，手环200和手机100通过蓝牙连接，手机100和电脑300则通过各自的消息通道组件所配置的私有通信协议连接。

当正在使用的一项基于多设备互联的功能异常中断时，例如通过手环200和电脑300接听手机100的通话且通话异常中断时，使用者在手机100上执行上报操作。

采集应用响应于上报操作，确定本次故障的标识符和特性码。

其中，标识符可以视为一个用于唯一标识本次发生的故障字符串。也就是说，每次发生故障后电子设备上报日志数据时均会产生一个标识符，并且每两次故障的标识符互不相同。

采集应用可以基于任意算法确定标识符，本实施例对具体的确认方法不做限定。

作为一个示例，采集应用可以根据接收到上报操作时的时间戳和手机100的设备编码(例如手机100的序列号，Serial Number，简称SN码)运算后得到本次故障的标识符。

特性码可以视为一个用于指示需要采集的日志数据的字符串，根据特性码，采集模块可以确定需要采集哪些日志数据，从而有选择的采集对应的日志数据。

在一些实施例中，特性码可以包括发生故障的应用的名称，采集模块获得特性码后，可以根据特性码采集发生故障的应用产生的日志数据。

在一些实施例中，特性码可以包括发生故障的应用的名称，故障类型等信息，采集模块获得特性码后，可以根据特性码采集发生故障的应用产生的与故障类型相关的日志数据。

采集应用可以在使用者执行上报操作之前显示特定的用户界面，以提示用户输入发生故障的应用的名称和故障类型等信息。

作为一个示例，请参见图5，为本申请提供的采集应用的用户界面示意图。当使用者通过手环200和电脑300接听手机100的通话且通话异常中断后，使用者打开手机100上的采集应用，采集应用显示图5的(1)所示的界面，图5的(1)用于提示使用者选择当前设备的类型。

在使用者选择“手机”后，采集应用显示图5的(2)所示的界面，该界面显示有多种手机可能发生的故障功能供使用者选择。

使用者选择“多设备互联”后，采集应用显示图5的(3)所示的界面，图5的界面(3)显示有多设备互联涉及的各项功能，使用者可以选择其中发生故障的功能。

使用者选择“智慧通话”后，采集应用显示图5的(4)所示的界面，图5的界面(4)用于显示多种故障类型，使用者可以根据实际的使用体验在其中选择对应的故障描述。

使用者选择“声音不清晰”后，采集应用显示图5的界面(5)，在界面(5)中，使用者可以输入故障的详细信息，例如故障时间，故障发生的概率，详细描述等，输入完上述信息后，使用者可以点击提交按钮。

其中，点击提交按钮这一操作就可以视为前述上报操作，在使用者点击提交按钮后，采集应用就开始确定标识符和特性码，并分别向连接应用和采集模块发送。

需要说明，图5所示的界面仅仅是本实施例中采集应用显示的用户界面的示例，在实际应用中，采集应用所显示的界面可以和图5相同或不同。

可以看出，基于使用者在图5的界面(3)的选择，采集应用可以确定发生故障的应用为“智慧通话”应用，基于使用者在图5的界面(4)的选择，采集应用可以确定故障类型为声音不清晰。

本实施例对特性码的确定方法和具体形式不做限定，只要特性码能够至少包含发生故障的应用的名称，或者根据特性码能够确定发生故障的应用的名称即可。示例性的，采集应用可以直接将发生故障的应用的名称确定为特性码，或者采集应用也可以将发生故障的应用的名称和发生故障的时间等信息组合成特性码。

一方面，采集应用确定标识符后，执行步骤A1，向连接应用发送标识符。

连接应用收到标识符后，执行步骤A2，向和手机100连接的手环200发送数据采集命令。数据采集命令用于指示手环200采集日志数据。

手环200的命令解析模块解析收到的数据采集命令，然后执行步骤A3，将解析后的数据采集命令发送给手环200的日志任务模块，日志任务模块用于管理手环200当前保存的日志数据。

日志任务模块响应数据采集命令，执行步骤A4，将手环200当前保存的全部日志数据均发送给回传模块，然后回传模块执行步骤A5，将日志任务模块提供的日志数据反馈给手机100的连接应用。

连接应用接收手环200反馈的日志数据，将手环200反馈的日志数据和采集应用发送的标识符打包，得到一个包含标识符和手环200的日志数据的压缩包，然后执行步骤A6，向云端上传该压缩包。

在一些可选的实施例中，上传模块生成的压缩包的名称中，可以包含所属的电子设备的产品类型和型号等信息，以便云端收到压缩包后，确定该压缩包中的日志数据属于哪一款电子设备。

需要说明的是，手机100的连接应用可以在用户无感知的情况下，在后台执行上述过程中相关的步骤。

还需要说明的是，由于内存较小，手环200仅保存最近的预设时间段内产生的少量日志数据，例如仅保存最近30分钟内产生的日志数据，不保存30分钟之前产生的日志数据，并且保存的日志数据的数据量也较小，因此，在采集手环200的日志数据时可以不区分日志数据是否由发生故障的应用产生，也不需要指示采集哪一时间段的日志数据。

另一方面，采集应用确定标识符和特性码后，执行步骤A7，向采集模块发送标识符和特性码。

采集模块接收标识符和特性码后，一方面可以执行步骤A8，根据特性码确定发生故障的应用，采集发生故障的应用对应的日志数据，然后将采集到的日志数据和标识符一并发送给上传模块。

示例性的，特性码可以包括“智慧通话”应用的名称，采集模块根据特性码确定发生故障的应用为“智慧通话”应用，于是采集“智慧通话”应用的日志数据，将“智慧通话”应用的日志数据和标识符一并发给上传模块。

上传模块将采集模块提供的日志数据和标识符打包，得到一个包含日志数据和标识符的压缩包，然后执行步骤A9，将压缩包上传到云端。

在一些可选的实施例中，上传模块生成的压缩包的名称中，可以包含所属的电子设备的产品类型和型号等信息，以便云端收到压缩包后，确定该压缩包中的日志数据属于哪一款电子设备。示例性的，手机100的上传模块生成的压缩包的名称可以包含“手机，型号为XX”的信息，云端收到该压缩包后即可确定该压缩包中的日志数据为型号为XX的手机的日志数据。

在一些可选的实施例中，采集模块可以采集手机100当前保存的全部由发生故障的应用产生的日志数据。

在一些可选的实施例中，采集模块可以仅采集手机100中发生故障的应用在预设时间段内产生的日志数据。作为一个示例，采集模块可以仅采集“智慧通话”应用在最近30分钟内产生的日志数据，不采集在30分钟之前产生的日志数据。

仅采集预设时间段内的日志数据的好处在于，减少需要上传到云端的日志数据的数据量，减少上报日志数据所消耗的流量。

采集模块收到标识符和特性码之后，另一方面可以执行步骤A10，将标识符和特性码发送给互助采集模块，互助采集模块再执行步骤A11，将标识符和特性码发送给消息通道组件，然后手机100的消息通道组件执行步骤A12，基于预先配置的私有通信协议广播标识符和特性码。

同时，电脑300和手机100连接后，电脑300的消息通道组件基于相同的私有通信协议持续进行监听，当手机100的消息通道组件广播标识符和特性码之后，电脑300的消息通道组件即可接收到广播的标识符和特性码。

电脑300的消息通道组件收到广播的标识符和特性码之后，执行步骤A13，将标识符和特性码发送给电脑300的互助采集模块，电脑300的互助采集模块再执行步骤A14，将标识符和特性码发送给电脑300的采集模块。

需要说明，电脑300的操作系统不为安卓操作系统，在电脑300中，采集模块相当于采集应用内的一个插件。

电脑300的采集模块执行步骤A15，根据收到的特性码确定发生故障的应用，然后采集电脑300中由发生故障的应用产生的日志数据，将采集到的日志数据和接收的标识符发送给电脑300的上传模块。

和手机100的上传模块相同，电脑300的上传模块收到采集模块提供的日志数据和标识符后，执行步骤A16，将日志数据和标识符打包，得到一个包含日志数据和标识符的压缩包，然后将压缩包上传到云端。

类似的，电脑300的上传模块生成的压缩包的名称，可以包含产品类型为电脑，型号为YY等信息，以便云端确定压缩包中的日志数据为对应型号的电脑的日志数据。

云端收到手机100，手环200和电脑300的三个压缩包后，根据其中的标识符可以确定这三个压缩包中的日志数据是手机100，手环200和电脑300针对同一次故障分别上传的日志数据，因此云端将具有相同标识符的这三个压缩包关联展示，展示方式可以参见图4。其中，单号可以由云端根据压缩包中的标识符生成，也可以直接以标识符作为单号，各个压缩包的时间为云端收到该压缩包的时间。

本实施例的好处在于，当相互建立通信连接的多个电子设备中任意一个或多个电子设备发生故障，导致基于多设备互联实现的功能异常中断或出错时，使用者只需要在其中的一个电子设备，例如在手机100上执行上报操作，就可以触发该电子设备以及和该电子设备连接的其他电子设备一并向云端上传日志数据，不需要逐一在每一个电子设备上执行上报操作，提高了相互连接的多个电子设备向云端上传日志数据的效率。

除了在手机100上执行上报操作外，在一些可选的实施例中，使用者也可以在电脑300上执行上报操作，同样可以触发和电脑300连接的多个电子设备一并上传日志数据。请参见图6，为本实施例提供的另一种互联的多设备上报日志时的数据交互示意图。

手机100，手环200和电脑300相互建立通信连接，其中，手环200和手机100通过蓝牙连接，手机100和电脑300则通过各自的消息通道组件所配置的私有通信协议连接。

当正在使用的一项基于多设备互联的功能异常中断时，例如通过手环200和电脑300接听手机100的通话且通话异常中断时，使用者在电脑300上执行上报操作。

电脑300的采集应用响应于上报操作，确定本次故障的标识符和特性码。

标识符和特性码的确定方法可以参见前述实施例，不再赘述。

一方面，电脑300的采集应用确定标识符和特性码后，执行步骤B1，调用内置的采集模块插件，根据特性码采集对应的日志数据，然后将标识符和采集到的日志数据发送给电脑300的上传模块，电脑300的上传模块执行步骤B2，将标识符和电脑300的日志数据打包得到一个压缩包，然后向云端上传这个包含标识符和电脑300的日志数据的压缩包。

另一方面，电脑300的采集应用确定标识符和特性码之后，执行步骤B3，向电脑300的互助采集模块发送标识符和特性码，电脑300的互助采集模块执行步骤B4，将标识符和特性码发送给电脑300的消息通道组件，然后电脑300的消息通道组件执行步骤B5，基于配置的私有通信协议向已建立连接的电子设备广播标识符和特性码。

手机100的消息通道组件基于私有通信协议监听到上述标识符和特性码后，执行步骤B6，将标识符和特性码发送给手机100的互助采集模块，手机100的互助采集模块执行步骤B7，将标识符和特性码发送给手机100的采集模块。

手机100的采集模块接收标识符和特性码之后，一方面执行步骤B8，根据特性码采集手机100的日志数据，将标识符和采集到的日志数据发送给手机100的上传模块，然后手机100的上传模块执行步骤B9，将收到的日志数据和标识符打包，得到包含标识符和手机100的日志数据的压缩包，然后向云端上传压缩包。

手机100的采集模块接收标识符和特性码之后，另一方面执行步骤B10，将标识符发送给手机100的连接应用，连接应用执行步骤B11，向和手机100蓝牙连接的手环200发送数据采集命令。

手环200的命令解析模块执行步骤B12，解析收到的数据采集命令，将解析后的数据采集命令发送给日志任务模块，日志任务模块执行步骤B13，采集手环200当前保存的日志数据，将采集到的日志数据发送给回传模块。然后回传模块执行步骤B14，将手环200的日志数据反馈给手机100的连接应用，手机100的连接应用执行步骤B15，将标识符和手环200的日志数据打包，然后将获得的包含标识符和手环200的日志数据的压缩包上传给云端。

最后，云端将包含相同标识符的手环200的压缩包，手机100的压缩包和电脑300的压缩包关联展示。

可以理解的，图4和图6所示的实施例，仅是本申请提供的多设备日志上报的方法在图1所示的场景下的实施时的一个示例。在实际应用中，本申请提供的多设备日志上报的方法可以适用于相互连接的任意多个种类不限的电子设备。例如，手机和大屏连接，手机同时连接蓝牙耳机和大屏，手机同时连接两台电脑，多台电脑相互连接等场景中，相互连接的多个电子设备均可以实施本申请提供的多设备日志上报的方法，使得其中单个电子设备接收上报操作后，触发其他电子设备一并向云端上传日志数据。

需要说明，本实施例中各个步骤的执行顺序仅作为一种可选的示例，在实际应用中上述各个步骤的执行顺序可以根据需要设定。例如，图4所示的实施例中，手机100的采集应用可以先执行步骤A7，后执行步骤A1；图6所示的实施例中，电脑300的采集模块可以先执行步骤B3，后执行步骤B1；本实施例对各个步骤的执行顺序不做限定。

根据上述实施例，可以得到一种多设备日志上报的方法，请参见图7和图8，为本实施例提供的多设备日志上报的方法的时序图。

如图7所示，本实施例提供的一种多设备日志上报的方法可以包括如下步骤：

S701，响应上报操作，上传标识符和根据特性码采集的手机日志数据。

在S701中，手机100的采集应用可以响应上报操作而确定标识符和特性码，然后将标识符和特性码发送给采集模块，采集模块根据特性码采集手机日志数据后，手机100的上传模块将标识符和手机日志数据打包上传给云端。S701的具体实施方式可以参见图4所示实施例中步骤A7至A9，不再赘述。

S702，向电脑发送标识符和特性码。

手机100通过自身的消息通道组件广播标识符和特性码，电脑300的消息通道组件则通过监听广播接收手机100发送的标识符和特性码。S702的具体实施方式可以参见图4所示实施例的步骤A10至A12。

S703，上传标识符和根据特性码采集的电脑日志数据。

电脑300收到手机100发送的标识符和特性码后，电脑300的采集模块即可根据特性码采集对应的电脑日志数据，然后电脑300的上传模块将电脑日志数据和标识符打包上传到云端。S703的具体实施方式可以参见图4所示实施例的步骤A13至A16。

可以理解的，步骤S701至S703的执行顺序并不限于本实施例，而是可以按需变更，例如手机100可以先执行步骤S702，后执行步骤S701，本实施例对上述步骤的执行顺序不做限定。

S704，向手环发送数据采集命令。

手机100的采集应用可以在确定标识符后将标识符发送给连接应用，触发连接应用向手环200发送数据采集命令。S704的具体实施方式可以参见图4所示实施例的步骤A1至A2。

S705，响应数据采集命令，向手机反馈手环的日志数据。

手环200收到数据采集命令后，采集手环200当前保存的全部日志数据，然后将日志数据反馈给手机100。S705的具体实施方式可以参见图4所示实施例的步骤A3至A5。

S706，上传标识符和手环的日志数据。

手机100的连接应用收到手环200反馈的日志数据后，将手环日志数据和标识符打包并上传给云端。S706的具体实施方式可以参见图4所示实施例的步骤A6。

如图8所示，本实施例提供的另一种多设备日志上报的方法可以包括如下步骤：

S801，响应上报操作，上传标识符和根据特性码采集的电脑日志数据。

电脑300的采集应用响应上报操作，确定标识符和特性码，然后利用内置的采集模块插件采集电脑300的日志数据，采集到的电脑日志数据和标识符由电脑300的上传模块打包并上传到云端。S801的具体实施方式可以参见图6所示实施例的步骤B1和B2。

S802，向手机发送标识符和特性码。

确定标识符和特性码后，电脑300通过自身的消息通道组件广播标识符和特性码，手机100的消息通道组件可以通过监听广播而接收电脑300发送的标识符和特性码。S802的具体实施方式可以参见图6所示实施例的步骤B3至B5。

需要说明，步骤S801和S802的执行顺序可以按需调整，例如可以先执行S802后执行S801，本实施例对此不作限定。

S803，上传标识符和根据特性码采集的手机日志数据。

获得标识符和特性码后，手机100的采集模块根据特性码采集对应的手机日志数据，然后手机100的上传模块将手机日志数据和标识符打包后上传给云端。S803的具体实施方式可以参见图6所示实施例的步骤B6至B9。

S804，向手环发送数据采集命令。

手机100的采集模块可以在收到标识符后将标识符发送给连接应用，触发连接应用向手环200发送数据采集命令。S804的具体实施方式可以参见图6所示实施例的步骤B10和B11。

需要说明，步骤S803和S804的执行顺序可以按需调整，例如可以先执行S804后执行S803，本实施例对此不作限定。

S805，响应于数据采集命令，向手机反馈手环日志数据。

手环200收到数据采集命令后，采集手环200当前保存的全部日志数据，然后将日志数据反馈给手机100。S805的具体实施方式可以参见图6所示实施例的步骤B12至B14。

S806，上传标识符和手环日志数据。

手机100的连接应用收到手环200反馈的日志数据后，将手环日志数据和标识符打包并上传给云端。S806的具体实施方式可以参见图6所示实施例的步骤B15。

上述多设备日志上报的方法的有益效果可以参见图4对应的实施例，不再赘述。

实施例二

本实施例中，电子设备上运行的应用程序可以在检测出故障时自动触发所在的电子设备和已建立通信连接的其他电子设备采集并上报日志数据。

请参见图9，为本实施例提供的又一种互联的多设备上报日志时的数据交互示意图。

手机100的应用程序运行时，确定自身出现故障，产生故障码，执行步骤C1，将故障码发送给手机100的互助采集模块。

手机和电脑上安装的应用程序中设置有故障检测代码，故障检测代码可以在应用程序运行时，根据运行产生的数据确定应用程序是否出现故障，如果在应用程序运行时故障检测代码确定出现故障，故障检测代码可以产生预先设定的故障码，然后由应用程序将故障码发送给互助采集模块。

其中，故障码用于说明应用程序中发生故障的组件，故障的类型等信息。

作为一个示例，故障检测代码产生的故障码可以是950XXXXX，950用于说明该故障码由应用程序的故障检测代码自动检测产生。

一方面，手机100的互助采集模块接收故障码后，执行步骤C4，向接口转换模块发送哈希序列码，并且执行步骤C2，根据故障码确定需要采集的日志数据，然后采集手机100中对应的日志数据，将哈希序列码，采集到的日志数据和预设的手机本地码发送给手机100的上传模块。

手机100的上传模块将哈希序列码，采集到的日志数据和预设的手机本地码压缩为压缩包，然后执行步骤C3，向云端上传该压缩包。

在一些可选的实施例中，手机100的上传模块产生的压缩包中，可以包括哈希序列码，采集到的日志数据，预设的手机本地码，以及表示上传模块产生该压缩包的时间戳，该时间戳可以称为打包时间戳。

哈希序列码，是指对手机100的SN码进行哈希运算后得到的编码。

手机本地码，是一个用于在手机和电脑连接期间用于唯一标识手机100的一个字符串。手机本地码可以在手机100和电脑300建立连接时确定。

每次多个手机、电脑和平板电脑等富设备通过各自的消息通道组件建立连接时，其中每个富设备都会确定一个用于在本次连接期间标识自身的编码，也就是本地码，也可以称为localuuid。本申请中，为便于区分，将手机100的本地码记为手机本地码，将电脑300的本地码记为电脑本地码。

各个富设备的本地码，可以在建立连接的过程中由各富设备协商确定，也可以由云端确定并分别下发给对应的富设备，本实施例对具体的确定方式不做限定。

手机100的接口转换模块收到哈希序列码后，执行步骤C5，将哈希序列码发送给连接应用，连接应用响应于接收的哈希序列码，执行步骤C6，向手环200发送数据采集命令。

手环200的命令解析模块解析收到的数据采集命令后，执行步骤C7，将解析后的数据采集命令发送给日志任务模块，日志任务模块采集手环200当前保存的日志数据，然后执行步骤C8，将采集到的日志数据发送给回传模块。

回传模块获得日志数据后，执行步骤C9，将手环200的日志数据反馈给手机100的连接应用。

手机100的连接应用将哈希序列码和手环200的日志数据打包，然后执行步骤C10，将产生的压缩包上传给云端。手机100的连接应用产生的压缩包，可以包括哈希序列码，手环200的日志数据，以及该压缩包的打包时间戳，即表示连接应用产生该压缩包的时间的时间戳。

另一方面，手机100的互助采集模块收到故障码之后，还执行步骤C11，通过内置的双端上报插件将故障码，远程码和手机本地码发送给手机100的消息通道组件，手机100的消息通道组件执行步骤C12，广播故障码，远程码和手机本地码，电脑300的消息通道组件通过监听手机100的广播，接收上述故障码，远程码和手机本地码。

远程码，也可以称为remoteuuid。对于成功建立连接的多个富设备，每个富设备都具有若干个远程码，每一个远程码均和该富设备连接的另一个富设备的本地码一致，由此，每个富设备可以根据自身记录的远程码确定当前连接的是哪些富设备。

在一些可选的实施例中，多个富设备成功建立连接后，每个富设备均通过消息通道组件广播自身的本地码，同时监听相连接的其他富设备广播的本地码，然后将其他富设备的本地码保存为自身的远程码。进一步的，每个富设备还将保存的远程码和自身的本地码上传到云端，以便云端确定是哪几个富设备建立了连接。

以图9为例，手机100和电脑300建立连接后，电脑300广播电脑本地码，手机100通过监听电脑300的广播获得电脑本地码，然后将电脑本地码保存为手机100的远程码，最后，手机100将远程码(也即电脑本地码)和手机本地码一并上传到云端。

在另一些可选的实施例中，富设备的远程码也可以由云端下发。云端将每个富设备的本地码下发给对应的富设备后，进一步将每一个富设备的本地码确定为其他富设备的远程码，然后将富设备的远程码下发给对应的富设备。

以图9为例，手机100和电脑300建立连接时，云端分别为手机100和电脑300分配不同的本地码，然后将分配给手机100的本地码下发给手机100，将分配给电脑300的本地码下发给电脑300。

手机100的本地码和电脑300的本地码均可以记录在对应设备的互助采集模块中。

可以理解，当有三个及以上的富设备相互连接时，每个富设备会有两个及以上的远程码，此时，富设备在广播故障码，远程码和手机本地码时，可以广播自身记录的全部远程码。

仍以图9为例，假设除电脑300外，手机100还连接了一台平板电脑，因此，手机100记录的远程码有两个，分别记为远程码1和远程码2，其中远程码1为电脑300的本地码，远程码2为平板电脑的本地码。

相应的，手机100的互助采集模块在收到应用程序发送的故障码后，通过双端上报插件将故障码，远程码1，远程码2和手机本地码一并发送给手机100的消息通道组件，然后手机100的消息通道组件广播故障码，远程码1，远程码2和手机本地码。

电脑300的消息通道组件收到手机100的广播后，执行步骤C13，向电脑300的互助采集模块中的双端上报插件发送收到的故障码，远程码和手机本地码。

随后，电脑300的互助采集模块执行步骤C14，获得故障码和电脑本地码(即电脑300的本地码)。其中，故障码可以从消息通道组件发送的信息读取，电脑本地码则由电脑300在和手机100建立连接时确定并记录在电脑300的互助采集模块中，确定电脑本地码的方法请参见前文。

电脑300的互助采集模块获得故障码后，根据故障码采集对应的电脑300的日志数据，然后执行步骤C15，将电脑300的日志数据和电脑本地码发送给电脑300的上传模块。

电脑300的上传模块将日志数据和电脑本地码压缩为压缩包，然后执行步骤C16，向云端上传该压缩包。

在一些可选的实施例中，电脑300的上传模块产生的压缩包中，可以包括电脑300的日志数据，电脑本地码，以及表示上传模块产生该压缩包的时间戳，该时间戳可以称为打包时间戳。

在一些可选的实施例中，手机100的上传模块0和电脑300的上传模块生成的压缩包的名称中，可以包含所属的电子设备的产品类型和型号等信息，以便云端收到压缩包后，确定该压缩包中的日志数据属于哪一款电子设备。具体实施方式可以参见实施例一，不再赘述。

云端收到上述压缩包，可以按如下方式确定各个压缩包之间的关联关系，即确定哪些压缩包是多个电子设备针对同一故障分别上传的压缩包：

云端收到手机压缩包后，根据手机压缩包中的手机本地码，确定该压缩包中的日志数据为手机100的日志数据；云端收到电脑的压缩包后，比对电脑的压缩包中的电脑本地码和预先记录的手机100的远程码，并确定两者一致，由此云端可以确定电脑压缩包的日志数据是电脑300响应于手机100的触发而采集的日志数据；云端收到手环压缩包后，比对手环压缩包的哈希序列码和手机100的哈希序列码，并确定两者一致，由此云端可以确定手环压缩包的日志数据是手环200响应于手机100的触发而采集的日志数据。

综上所述，云端根据压缩包中携带的本地码和哈希序列码，以及云端预先记录的远程码，可以将手环，手机和电脑上传的压缩包中的日志数据针对同一次故障分别上传的不同电子设备的日志数据，从而将各个压缩包中的日志数据关联展示。

根据上述实施例，可以得到一种多设备日志上报的方法，请参见图10，为本实施例提供的又一种多设备日志上报的方法的时序图。

如图10所示，本实施例提供的又一种多设备日志上报的方法可以包括如下步骤：

S1001，应用程序发生故障后，上传手机身份信息和根据故障码采集的手机日志数据。

上述手机身份信息可以包括前述手机本地码和哈希序列码等信息。

手机100的应用程序发生故障后产生故障码并向手机100的互助采集模块发送故障码，手机100的互助采集模块根据故障码采集对应的手机日志数据，然后手机100的上传模块将手机日志数据，手机本地码和哈希序列码打包上传给云端。S1001的具体实施方式可以参见步骤C1至C3。

S1002，向电脑发送故障码。

手机100的互助采集模块获得故障码后，通过双端上报插件和消息通道组件广播故障码，电脑300的消息通道组件通过监听广播接收故障码。

在一些可选的实施例中，手机100执行S1002时还可以向电脑发送远程码和手机本地码。

S1002的具体实施方式可以参见图9所示实施例的步骤C11和C12。

S1003，上传电脑身份信息和根据故障码采集的电脑日志数据。

上述电脑身份信息可以包括前述电脑本地码。

电脑300的消息通道组件收到手机100广播的故障码后，将故障码发送给电脑300的互助采集模块，电脑300的互助采集模块根据故障码采集对应的电脑日志数据，然后由电脑300的上传模块将电脑日志数据和电脑本地码打包后上传给云端。S1003的具体实施方式可以参见图9所示实施例的步骤C13至C16。

S1004，向手环发送数据采集命令。

手机100的互助采集模块可以在收到故障码后，向连接应用发送手机的哈希序列码，触发连接应用向手环200发送数据采集命令。S1004的具体实施方式可以参见图9所示实施例的步骤C4至C6。

需要说明，步骤S1001至S1004的执行顺序可以按需调整，本实施例对此不作限定。

S1005，响应于数据采集命令，向手机反馈手环日志数据。

手环200收到数据采集命令后，采集手环200当前保存的全部日志数据，然后将日志数据反馈给手机100。S1005的具体实施方式可以参见图9所示实施例的步骤C7至C9。

S1006，上传手环日志数据和哈希序列码。

手机100的连接应用收到手环200反馈的日志数据后，将手环日志数据和手机的哈希序列码打包并上传给云端。S1006的具体实施方式可以参见图9所示实施例的步骤C10。

本实施例的有益效果在于，当相互连接的多个电子设备中任意一个或多个的应用程序出现故障，导致基于多设备互联而实现的功能(例如投屏，智慧通话)异常中断时，可以由其中任意一个电子设备自动触发相互连接各个电子设备采集并上报日志数据，提高了相互连接的多个电子设备在出现问题时向云端上传日志数据的效率。

在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

本申请实施例涉及的多个，是指大于或等于两个。需要说明的是，在本申请实施例的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

Claims (10)

1.一种多设备日志上报的方法，其特征在于，应用于第一设备，所述第一设备和第二设备通信连接，所述方法包括：

基于所述通信连接的功能出现故障后，所述第一设备采集第一日志数据，所述第一日志数据为所述第一设备的日志数据；

所述第一设备向云端上报所述第一日志数据；

所述第一设备向所述第二设备发送通知消息，以触发所述第二设备向云端上报第二日志数据，所述第二日志数据为所述第二设备的日志数据。

2.根据权利要求1所述的方法，其特征在于，还包括：

所述第一设备向第三设备发送数据采集命令，所述第一设备和所述第三设备通信连接，所述第三设备不具有联网能力；

所述第一设备接收所述第三设备反馈的第三日志数据，所述第三日志数据为所述第三设备的日志数据；

所述第一设备向云端上报所述第三日志数据。

3.根据权利要求1所述的方法，其特征在于，所述通知消息包括所述第一设备确定的用于标记所述故障的标识符；

所述第一设备向云端上报所述第一日志数据，包括：

所述第一设备向云端上报所述第一日志数据和所述标识符；

所述第二设备向云端上报第二日志数据，包括：

所述第二设备向云端上报第二日志数据和所述标识符。

4.根据权利要求3所述的方法，其特征在于，还包括：

所述第一设备响应于上报操作，确定特性码；

所述第一设备采集第一日志数据，包括：

所述第一设备根据所述特性码采集所述日志数据；

所述通知消息包括所述特性码。

5.根据权利要求1所述的方法，其特征在于，所述第一设备采集第一日志数据，包括：

所述第一设备响应于预设的故障检测代码产生的故障码，根据所述故障码采集所述第一日志数据；

所述通知消息包括所述故障码。

6.根据权利要求5所述的方法，其特征在于，所述第一设备向云端上报所述第一日志数据，包括：

所述第一设备向云端上报所述第一日志数据和所述第一设备的本地码；

所述第二设备向云端上报第二日志数据，包括：

所述第二设备向云端上报第二日志数据和所述第二设备的本地码；

所述第二设备的本地码和云端记录的所述第一设备的远程码相同。

7.一种多设备日志上报的方法，其特征在于，应用于第二设备，所述第二设备和第一设备通信连接，所述方法包括：

所述第二设备响应于所述第一设备的通知消息，采集第二日志数据，所述第二日志数据为所述第二设备的日志数据；

所述第二设备向云端上报所述第二日志数据。

8.根据权利要求7所述的方法，其特征在于，还包括：

所述第二设备向第四设备发送数据采集命令，所述第二设备和所述第四设备通信连接，所述第四设备不具有联网能力；

所述第二设备接收所述第四设备反馈的第四日志数据，所述第四日志数据为所述第四设备的日志数据；

所述第二设备向云端上报所述第四日志数据。

9.根据权利要求7所述的方法，其特征在于，所述通知消息包括所述第一设备确定的特性码；

所述第二设备响应于所述第一设备的通知消息，采集第二日志数据，包括：

所述第二设备响应于所述第一设备的通知消息，根据所述通知消息中的故障码采集第二日志数据。

10.一种多设备日志上报的系统，其特征在于，包括第一设备，第二设备和云端，所述第一设备和所述第二设备通信连接；

基于所述通信连接的功能出现故障后，所述第一设备用于向所述云端上报第一日志数据，所述第一日志数据为所述第一设备的日志数据；

所述第二设备用于被所述第一设备触发后，向所述云端上报第二日志数据，所述第二日志数据为所述第二设备的日志数据；

所述云端用于展示所述第一日志数据和所述第二日志数据。

Images