沙箱运行环境的检测方法及检测装置与流程

本发明涉及计算机技术领域，具体而言，本发明涉及一种沙箱运行环境的检测方法，及一种沙箱运行环境的检测装置。

背景技术：

随着时代的发展，各种终端设备已成为人们生活中必不可少的工具，各种功能强大的终端操作系统及终端应用程序不断涌现，为用户带来了更加便捷的体验。现有技术中，应用程序在终端设备的系统环境中仅可以唯一的形式安装并运行，如对于一种即时通信类应用程序，在一台终端设备中仅可以安装并运行一个该即时通信类应用程序，用户仅可以通过唯一的账号登录并对其执行相关操作。但是，随着即时通信类应用程序的普及，越来越多的用户希望在一台终端设备中通过多个账号登录一种即时通信类应用程序以实现对不同好友信息的区分管理及交流。现有技术中，利用沙箱技术，使得目标应用程序可实现原生应用程序的全部功能及相应服务，但是，由于Android设备种类繁多，品牌众多，版本各异，分辨率不统一等等导致了Android系统的碎片越来越严重，从而使得沙箱难免会崩溃，一般情况下，只能对将沙箱所有已经启动的应用程序全部退出，再由用户重启沙箱，以重启各个应用程序。通过该方式对沙箱进行重启，用户能感觉到沙箱的闪退过程，严重影响了用户的使用体验。

因此，亟需一种沙箱运行环境的检测方法，使得用户在无感知的状态下，快速的重启沙箱运行环境。

技术实现要素：

为克服上述技术问题或者至少部分地解决上述技术问题，特提出以下技术方案：

本发明的实施例提出了一种沙箱运行环境的检测方法，沙箱由服务器沙箱及客户端沙箱构成，包括：

检测到服务器沙箱运行环境崩溃的通知消息后，服务器沙箱的Task管理器接收来自客户端沙箱中各个应用程序发送的建立连接的多个第一请求；

基于第一请求，服务器沙箱的Task管理器建立与客户端沙箱中各个应用程序的多个第一连接关系；

基于多个第一连接关系，服务器沙箱的Task管理器接收客户端沙箱中各个应用程序发送的其各自的Task表中的相关数据；

基于Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态。

可选地，检测到服务器沙箱运行环境崩溃的通知消息后，还包括：

初始化服务器沙箱运行环境以重启服务器沙箱，并初始化服务器沙箱的Task管理器。

可选地，还包括：

服务器沙箱的Task管理器监测到客户端沙箱中任一应用程序启动后，接收来自客户端沙箱中已启动的应用程序发送建立连接的第二请求；

响应于第二请求，服务器沙箱的Task管理器建立与应用程序与的第二连接关系。

可选地，服务器沙箱的Task管理器监测到客户端沙箱中任一应用程序启动后，还包括：

基于已建立的第二连接关系，服务器沙箱的Task管理接收来自客户端沙箱中已启动的应用程序发送的Task数据表。

优选地，Task数据表包括客户端操作系统中与已启动的应用程序相匹配的Activity组件的相关数据、以及与Activity组件相匹配的系统级别的Task信息。

可选地，还包括：

当监测到服务器沙箱重启后，接收到来自客户端沙箱发送的客户端操作系统Task信息中与沙箱相关的Task信息；

基于接收到的客户端操作系统Task信息中与沙箱相关的Task信息、以及Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态。

本发明的另一实施例提出了一种沙箱运行环境的检测装置，沙箱由服务器沙箱及客户端沙箱构成，包括：

检测及发送模块，用于检测到服务器沙箱运行环境崩溃的通知消息后，服务器沙箱的Task管理器接收来自客户端沙箱中各个应用程序发送的建立连接的多个第一请求；

第一建立模块，用于基于第一请求，服务器沙箱的Task管理器建立与客户端沙箱中各个应用程序的多个第一连接关系；

第一接收模块，用于基于多个第一连接关系，服务器沙箱的Task管理器接收客户端沙箱中各个应用程序发送的其各自的Task表中的相关数据；

第一恢复模块，用于基于Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态。

可选地，检测到服务器沙箱运行环境崩溃的通知消息后，还包括：

初始化模块，用于初始化服务器沙箱运行环境以重启服务器沙箱，并初始化服务器沙箱的Task管理器。

可选地，还包括：

监测及接收模块，用于服务器沙箱的Task管理器监测到客户端沙箱中任一应用程序启动后，接收来自客户端沙箱中已启动的应用程序发送建立连接的第二请求；

第二建立模块，用于响应于第二请求，服务器沙箱的Task管理器建立与应用程序与的第二连接关系。

可选地，服务器沙箱的Task管理器监测到客户端沙箱中任一应用程序启动后，还包括：

第二接收模块，用于基于已建立的第二连接关系，服务器沙箱的Task管理接收来自客户端沙箱中已启动的应用程序发送的Task数据表。

优选地，Task数据表包括客户端操作系统中与已启动的应用程序相匹配的Activity组件的相关数据、以及与Activity组件相匹配的系统级别的Task信息。

可选地，还包括：

第三接收模块，用于当监测到服务器沙箱重启后，接收到来自客户端沙箱发送的客户端操作系统Task信息中与沙箱相关的Task信息；

第二恢复模块，用于基于接收到的客户端操作系统Task信息中与沙箱相关的Task信息、以及Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态。

本发明的实施例中，提出了一种沙箱运行环境的检测方案，检测到服务器沙箱运行环境崩溃的通知消息后，服务器沙箱的Task管理器接收来自客户端沙箱中各个应用程序发送的建立连接的多个第一请求，基于第一请求，服务器沙箱的Task管理器建立与客户端沙箱中各个应用程序的多个第一连接关系，实现了各个应用程序与服务器沙箱的Task管理器之间的通信，以使得服务器沙箱的Task管理器能够管理客户端沙箱中各应用程序的Task信息；基于多个第一连接关系，服务器沙箱的Task管理器接收客户端沙箱中各个应用程序发送的其各自的Task表中的相关数据，为将服务器沙箱的运行状态恢复至崩溃前的运行状态提供了必要的前提保障；基于Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态，实现了根据客户端沙箱中各个应用程序各自的Task表信息，在不影响用户使用体验的前提下，实现了在用户无感知的状态下即可准确快速地将服务器沙箱运行环境恢复至崩溃前的运行状态，以使得用户在客户端沙箱运行环境中能够平滑地继续正常使用各应用程序，提高了用户的使用体验，进一步地，通过沙箱运行环境能有效的对各应用程序进行权限的拦截、并对各应用程序的行为进行监控等，在一定程度上能解决因安卓系统上存在的诸多漏洞所带来的安全隐患问题。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明中一个实施例的沙箱运行环境的检测方法的流程图；

图2为本发明中一个优选实施例的服务器沙箱运行环境重启后Task管理器恢复沙箱运行环境的工作流程图；

图3为本发明中另一优选实施例的服务器沙箱运行环境崩溃前Task管理器的工作流程图；

图4为本发明中另一优选实施例的沙箱运行环境的检测装置的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

需要说明的是，本领域技术人员可以了解到，Android操作系统有其不同于其他操作系统的原理，Android为开发者提供四大组件，具体指Activity、Service、Broadcast Receiver以及Content Provider等组件。在日常应用中Activity是与用户交互的接口，它提供了一个用户完成相关操作的窗口。当在开发过程中创建Activity后，通过调用setContentView(View)方法来给该Activity指定一个布局界面，而这个界面就是提供给用户交互的接口。Android系统中是通过Activity栈的方式来管理Activity的，而Activity自身则是通过生命周期的方法来管理自己的创建与销毁。Activity栈是用户一系列操作中所打开的多个Activity，按显示顺序组织成的一个堆栈，最先打开的Activity位于最底部，最后打开的在顶端，只有顶端的Activity才是可见的，退出顶端Activity后堆栈中下一个Activity变为顶端，该Activity方可见。

Android沙箱的本质是为了实现不同应用程序和进程之间的互相隔离，即在默认情况下，应用程序没有权限访问系统资源或其它应用程序的资源。每个应用程序和系统进程都被分配唯一并且固定的User Id(用户标识信息)，该uid与内核层进程的uid相对应，同时，每个应用程序在各自独立的Dalvik虚拟机(用于Android平台的虚拟机)中运行，拥有独立的地址空间和资源。运行于Dalvik虚拟机中的进程必须依托内核层Linux进程而存在，因此Android使用Dalvik虚拟机和Linux的文件访问控制来实现沙箱机制，任何应用程序如果想要访问系统资源或者其它应用程序的资源必须在自己的manifest文件(它属于AndroidManifest.xml文件，每一个应用程序都要有一个manifest文件，它配置了应用程序在Android系统上的基本信息)中进行声明权限或者共享uid。应用程序进程之间，应用程序与操作系统之间的安全性由Linux操作系统的标准进程级安全机制实现。在默认状态下，应用程序之间无法交互，运行在进程沙箱内的应用程序没有被分配权限，无法访问系统或资源。因此，无论是直接运行于操作系统之上的应用程序，还是运行于Dalvik虚拟机的应用程序都得到同样的安全隔离与保护，被限制在各自“沙箱”内的应用程序互不干扰，对系统与其他应用程序的损害可降至最低。

Android任务栈又称为Task，它是一个栈结构，具有后进先出的特性，用于存放Activity组件。Task与Activity栈有些类似，每一个Task是一个Activity栈，Task将相关的Activity组合在一起，并以栈的方式进行管理，在Android操作系统中，每个应用程序一般情况拥有多个Task，通过系统管理各应用的Task，以及沙箱运行环境的相关Task，都将无法获取到每个应用对应的各个Task，因此，本发明的实施例中，在终端设备的沙箱运行环境中创建Task管理器，Task管理器提供可在沙箱中以独立进程对所有非沙箱Activity栈以Task形式进行管理的服务。

图1为本发明中一个实施例的沙箱运行环境的检测方法的流程图。

本发明的实施例中，各步骤所执行的内容概述如下：步骤S1010：检测到服务器沙箱运行环境崩溃的通知消息后，服务器沙箱的Task管理器接收来自客户端沙箱中各个应用程序发送的建立连接的多个第一请求；步骤S1020：基于第一请求，服务器沙箱的Task管理器建立与客户端沙箱中各个应用程序的多个第一连接关系；步骤S1030：基于多个第一连接关系，服务器沙箱的Task管理器接收客户端沙箱中各个应用程序发送的其各自的Task表中的相关数据；步骤S1040：基于Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态。

本发明的实施例中，提出了一种沙箱运行环境的检测方法，检测到服务器沙箱运行环境崩溃的通知消息后，服务器沙箱的Task管理器接收来自客户端沙箱中各个应用程序发送的建立连接的多个第一请求，基于第一请求，服务器沙箱的Task管理器建立与客户端沙箱中各个应用程序的多个第一连接关系，实现了各个应用程序与服务器沙箱的Task管理器之间的通信，以使得服务器沙箱的Task管理器能够管理客户端沙箱中各应用程序的Task信息；基于多个第一连接关系，服务器沙箱的Task管理器接收客户端沙箱中各个应用程序发送的其各自的Task表中的相关数据，为将服务器沙箱的运行状态恢复至崩溃前的运行状态提供了必要的前提保障；基于Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态，实现了根据客户端沙箱中各个应用程序各自的Task表信息，在不影响用户使用体验的前提下，实现了在用户无感知的状态下即可准确快速地将服务器沙箱运行环境恢复至崩溃前的运行状态，以使得用户在客户端沙箱运行环境中能够平滑地继续正常使用各应用程序，提高了用户的使用体验，进一步地，通过沙箱运行环境能有效的对各应用程序进行权限的拦截、并对各应用程序的行为进行监控等，在一定程度上能解决因安卓系统上存在的诸多漏洞所带来的安全隐患问题。以下针对各个步骤的具体实现做进一步的说明：

步骤S1010：检测到服务器沙箱运行环境崩溃的通知消息后，服务器沙箱的Task管理器接收来自客户端沙箱中各个应用程序发送的建立连接的多个第一请求。

例如，在服务器端，当检测服务器沙箱运行环境崩溃后，终端设备的客户端沙箱中的各个应用程序，如App1和App2，将接收到服务器沙箱运行环境崩溃的通知消息，随后，基于预定的频率，如每隔5分钟，终端设备的客户端沙箱中的应用程序App1和App2分别向服务器沙箱的Task管理器发送建立连接的第一请求，参考图2中的步骤B，相应的，服务器沙箱的Task管理器接收来自客户端沙箱中App1和App2发送的建立连接的多个第一请求。

优选地，步骤S1010检测到服务器沙箱运行环境崩溃的通知消息后还包括步骤S1050；步骤S1050：初始化服务器沙箱运行环境以重启服务器沙箱，并初始化服务器沙箱的Task管理器。

例如，在服务器端，当检测到服务器沙箱运行环境崩溃后，初始化服务器沙箱运行环境以重启沙箱，如声明适当的manifest权限，以用于启动客户端沙箱应用程序时将其与其他受信任的应用程序运行在同一进程中，从而共享对其数据和代码的访问等初始化操作；并初始化服务器沙箱的Task管理器，包括启动服务器沙箱的Task管理器，对服务器沙箱的Task管理器进行初始化相关配置，初始化跟踪终端设备客户端沙箱中各应用程序的Task运行的相关数据结构等操作。

步骤S1020：基于第一请求，服务器沙箱的Task管理器建立与客户端沙箱中各个应用程序的多个第一连接关系。

例如，服务器沙箱中的Task管理器响应于客户端沙箱中的应用程序App1向服务器沙箱的Task管理器发送建立连接的第一请求Request1，建立服务器沙箱的Task管理器与客户端沙箱中应用程序App1的第一连接关系，同时，应用程序App2向服务器沙箱的Task管理器发送建立连接的第一请求Request2，建立服务器沙箱的Task管理器与客户端沙箱中应用程序App2的第一连接关系，参考图2中的步骤C。

步骤S1030：基于多个第一连接关系，服务器沙箱的Task管理器接收客户端沙箱中各个应用程序发送的其各自的Task表中的相关数据。

例如，基于已建立的Task管理器与客户端沙箱中应用程序App1和App2各自的第一连接关系，App1和App2将各自的Task表中的相关数据发送至服务器沙箱Task管理器，服务器沙箱的Task管理器接收App1和App2发送的其各自的Task表中的相关数据，参考图2中的步骤D。

在本发明的实施例中，客户端沙箱运行环境中的各个应用程序，各自维护一个Task表，由于Task将相关的Activity组合在一起，并以栈的方式进行管理，因此Task表中记录着各个Activity的相关信息，因此，获取到各应用程序的各自的各个Activity的相关信息即可获取各个应用程序的运行相关信息。

步骤S1040：基于Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态。

例如，在终端设备的沙箱运行环境中包括应用程序App1和App2，基于应用程序App1和App2各自的Task表中的相关数据，可获取到应用程序App1和App2各自的运行状态相关信息，随后，将服务器沙箱的运行状态恢复至崩溃前的运行状态，以使得终端设备中的应用程序App1和App2的行状态能够与服务器沙箱崩溃前的运行状态保持一致，使得终端设备中的应用程序App1和App2能够正常运行。

需要说明的是，本发明的实施例中，可以通过服务器Task管理器将服务器沙箱的运行状态恢复至崩溃前的运行状态，也可以通过服务器沙箱中的其他恢复程序将服务器沙箱的运行状态恢复至崩溃前的运行状态，本发明的实施例中虽会以特定的恢复方式将服务器沙箱的运行状态恢复至崩溃前的运行状态，但在此不做限定。

优选地，该方法还包括步骤S1060和步骤S1070；步骤S1060：服务器沙箱的Task管理器监测到客户端沙箱中任一应用程序启动后，接收来自客户端沙箱中已启动的应用程序发送建立连接的第二请求；步骤S1070：响应于第二请求，服务器沙箱的Task管理器建立与应用程序与的第二连接关系。

例如，服务器沙箱的Task管理器监测到终端设备的客户端沙箱运行环境中的应用程序App1和App2启动后，App1和App2进行自我初始化相关操作后分别向服务器沙箱的Task管理器发送建立连接的第二请求Request3和Request4，Task管理器响应于第二请求Request3和Request4，分别建立与App1和App2的第二连接关系，参考图1中的步骤A和B。

优选地，步骤S1060中服务器沙箱的Task管理器监测到客户端沙箱中任一应用程序启动后，还包括步骤S1080；步骤S1080：基于已建立的第二连接关系，服务器沙箱的Task管理接收来自客户端沙箱中已启动的应用程序发送的Task数据表。

其中，Task数据表包括客户端操作系统中与已启动的应用程序相匹配的Activity组件的相关数据、以及与Activity组件相匹配的系统级别的Task信息。

例如，服务器沙箱的Task管理器监测到客户端沙箱运行环境中应用程序App1和App2启动后，终端设备Android操作系统的ActivityManager组件启动与应用程序App1和App2相匹配的Activity组件，如Activity组件1和Activity组件2，并分别建立与Activity组件1和Activity组件2相匹配的系统级别的Task信息，参考图3中的步骤D；ActivityManager组件将Activity组件1和Activity组件2成功启动后，在Activity.onCreate回调通知中，App1将自身的Activity和Task数据保存到App1的Task表中，App2将自身的Activity和Task数据保存到App2的Task表中，随后，ActivityManager组件将该启动后的Activity组件1的相关数据和App1的Task信息存储至应用程序App1的Task数据表中，并将该启动后的Activity组件2的相关数据和App2的Task信息存储至应用程序App2的Task数据表中，参考图3中的步骤E；随后基于已建立的服务器沙箱Task管理器与App1的第二连接关系，App1将自身的Task数据表发送至服务器沙箱Task管理器，基于已建立的服务器沙箱Task管理器与App2的第二连接关系，App2将自身的Task数据表发送至服务器沙箱Task管理器，参考图3中的步骤F，服务器沙箱的Task即可管理接收来自客户端沙箱中已启动的应用程序App1和App2发送的其各自的Task数据表。

通过本实施例，在沙箱运行环境中，服务器沙箱Task管理器预先获取客户端沙箱运行的状态信息进行保存，以确保服务器沙箱运行环境崩溃后，能够获取到服务器沙箱崩溃前的运行状态信息，为后续服务器沙箱重启后将服务器沙箱的运行状态恢复至崩溃前的运行状态提供了必要的前提保障。

本领域技术人员可以了解到，Android系统中的资源包括ActivityManagerService(AMS)资源、PackageManagerService资源、Activity组件、Service组件、Broadcast Receiver组件和Content Provider组件等。在Android操作系统中，AMS不仅用于管理所有应用程序进程的Activity的生命周期，它同时也管理着系统的Service、Broadcast Receiver以及Content Provider等组件。Android应用程序的真正入口是Application类的onCreate方法，应用程序创建以后就会调用onCreate，随后查找对应的Activity并创建，以执行一列Task的生命周期，因此，通过Application类的onCreate方法可获取到应用程序自身的Activity和Task数据。

优选地，该方法还包括步骤S1090和步骤S1100；步骤S1090：当监测到服务器沙箱重启后，接收到来自客户端沙箱发送的客户端操作系统Task信息中与沙箱相关的Task信息；步骤S1100：基于接收到的客户端操作系统Task信息中与沙箱相关的Task信息、以及Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态。

例如，在客户端沙箱运行环境中运行应用程序App1和App2，基于已建立的服务器沙箱Task管理器与App1和App2的各自第二连接关系，App1和App2将各自的Task数据表发送至服务器沙箱Task管理器，随后，服务器沙箱运行环境崩溃，当服务器沙箱Task管理器监测到服务器沙箱重启后，获取终端设备Android操作系统Task信息中与客户端沙箱相关的App1和App2的Task基本信息，基于获取到的App1和App2的Task基本信息，以及服务器沙箱Task管理器中接收到App1和App2各自的Task数据表信息，通过预定的算法，如通过各个应用程序的Task数据表信息得到各自对应的活动组件坑位，以使得服务器沙箱能够顺利重启，并得到服务器沙箱崩溃前的运行状态使得重启后的服务器沙箱恢复至崩溃前的运行状态，以使得终端设备中的应用程序App1和App2运行状态能够与服务器沙箱崩溃前的运行状态保持一致，使得终端设备中的应用程序App1和App2能够正常运行。

需要说明的是，本领域技术人员可以理解，Android系统中应用程序的配置文件Androidmanafest.xml中，各个Activity的注册信息可以视为独立注册信息模块，视为“坑位”。沙箱中运行的应用程可以向Android系统预注册多个activity组件坑位；出于预留的目的而在客户端沙箱中应用程序的Androidmanifest.xml配置文件中可以设置多个活动组件注册信息，但这些注册信息所指向的活动组件的真实内容并未确定。Android系统中，通过沙箱启动一个应用程序的Activity，由于该Activity是未知的，故沙箱无法在安装配置文件时对该应用程序进行事先声明，应用程序中的Activity是无法直接启动的，因此，可以形象地在配置文件中预留注册信息的活动组件，并在该配置文件提供给系统进行安装之后形成的活动组件虚拟单位称之为活动组件坑位，最终通过坑来代替应用程序中的Activity启动。

需要说明的是，本发明实施例中虽会以特定的预定算法为例说明，但在此不做限定。

通过本实施例，通过获取到的客户端操作系统Task信息中与沙箱相关的Task信息、以及Task表中的相关数据，能够更加准确地将服务器沙箱的运行状态恢复至崩溃前的运行状态，以使得客户端沙箱中的应用程序能够正常运行。

图4为本发明中另一优选实施例的沙箱运行环境的检测装置的结构示意图。

本发明的实施例中，各模块所执行的内容概述如下：检测及发送模块410检测到服务器沙箱运行环境崩溃的通知消息后，服务器沙箱的Task管理器接收来自客户端沙箱中各个应用程序发送的建立连接的多个第一请求；第一建立模块420基于第一请求，服务器沙箱的Task管理器建立与客户端沙箱中各个应用程序的多个第一连接关系；第一接收模块430基于多个第一连接关系，服务器沙箱的Task管理器接收客户端沙箱中各个应用程序发送的其各自的Task表中的相关数据；第一恢复模块440基于Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态。

本发明的实施例中，提出了一种沙箱运行环境的检测装置，检测到服务器沙箱运行环境崩溃的通知消息后，服务器沙箱的Task管理器接收来自客户端沙箱中各个应用程序发送的建立连接的多个第一请求，基于第一请求，服务器沙箱的Task管理器建立与客户端沙箱中各个应用程序的多个第一连接关系，实现了各个应用程序与服务器沙箱的Task管理器之间的通信，以使得服务器沙箱的Task管理器能够管理客户端沙箱中各应用程序的Task信息；基于多个第一连接关系，服务器沙箱的Task管理器接收客户端沙箱中各个应用程序发送的其各自的Task表中的相关数据，为将服务器沙箱的运行状态恢复至崩溃前的运行状态提供了必要的前提保障；基于Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态，实现了根据客户端沙箱中各个应用程序各自的Task表信息，在不影响用户使用体验的前提下，实现了在用户无感知的状态下即可准确快速地将服务器沙箱运行环境恢复至崩溃前的运行状态，以使得用户在客户端沙箱运行环境中能够平滑地继续正常使用各应用程序，提高了用户的使用体验，进一步地，通过沙箱运行环境能有效的对各应用程序进行权限的拦截、并对各应用程序的行为进行监控等，在一定程度上能解决因安卓系统上存在的诸多漏洞所带来的安全隐患问题。以下针对各个模块的具体实现做进一步的说明：

检测及发送模块410检测到服务器沙箱运行环境崩溃的通知消息后，服务器沙箱的Task管理器接收来自客户端沙箱中各个应用程序发送的建立连接的多个第一请求。

例如，在服务器端，当检测服务器沙箱运行环境崩溃后，终端设备的客户端沙箱中的各个应用程序，如App1和App2，将接收到服务器沙箱运行环境崩溃的通知消息，随后，基于预定的频率，如每隔5分钟，终端设备的客户端沙箱中的应用程序App1和App2分别向服务器沙箱的Task管理器发送建立连接的第一请求，相应的，服务器沙箱的Task管理器接收来自客户端沙箱中App1和App2发送的建立连接的多个第一请求。

优选地，检测到服务器沙箱运行环境崩溃的通知消息后还包括初始化模块；初始化模块初始化服务器沙箱运行环境以重启服务器沙箱，并初始化服务器沙箱的Task管理器。

例如，在服务器端，当检测到服务器沙箱运行环境崩溃后，初始化服务器沙箱运行环境以重启沙箱，如声明适当的manifest权限，以用于启动客户端沙箱应用程序时将其与其他受信任的应用程序运行在同一进程中，从而共享对其数据和代码的访问等初始化操作；并初始化服务器沙箱的Task管理器，包括启动服务器沙箱的Task管理器，对服务器沙箱的Task管理器进行初始化相关配置，初始化跟踪终端设备客户端沙箱中各应用程序的Task运行的相关数据结构等操作。

第一建立模块420基于第一请求，服务器沙箱的Task管理器建立与客户端沙箱中各个应用程序的多个第一连接关系。

例如，服务器沙箱中的Task管理器响应于客户端沙箱中的应用程序App1向服务器沙箱的Task管理器发送建立连接的第一请求Request1，建立服务器沙箱的Task管理器与客户端沙箱中应用程序App1的第一连接关系，同时，应用程序App2向服务器沙箱的Task管理器发送建立连接的第一请求Request2，建立服务器沙箱的Task管理器与客户端沙箱中应用程序App2的第一连接关系。

第一接收模块430基于多个第一连接关系，服务器沙箱的Task管理器接收客户端沙箱中各个应用程序发送的其各自的Task表中的相关数据。

例如，基于已建立的Task管理器与客户端沙箱中应用程序App1和App2各自的第一连接关系，App1和App2将各自的Task表中的相关数据发送至服务器沙箱Task管理器，服务器沙箱的Task管理器接收App1和App2发送的其各自的Task表中的相关数据。

在本发明的实施例中，客户端沙箱运行环境中的各个应用程序，各自维护一个Task表，由于Task将相关的Activity组合在一起，并以栈的方式进行管理，因此Task表中记录着各个Activity的相关信息，因此，获取到各应用程序的各自的各个Activity的相关信息即可获取各个应用程序的运行相关信息。

第一恢复模块440基于Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态。

例如，在终端设备的沙箱运行环境中包括应用程序App1和App2，基于应用程序App1和App2各自的Task表中的相关数据，可获取到应用程序App1和App2各自的运行状态相关信息，随后，将服务器沙箱的运行状态恢复至崩溃前的运行状态，以使得终端设备中的应用程序App1和App2的行状态能够与服务器沙箱崩溃前的运行状态保持一致，使得终端设备中的应用程序App1和App2能够正常运行。

需要说明的是，本发明的实施例中，可以通过服务器Task管理器将服务器沙箱的运行状态恢复至崩溃前的运行状态，也可以通过服务器沙箱中的其他恢复程序将服务器沙箱的运行状态恢复至崩溃前的运行状态，本发明的实施例中虽会以特定的恢复方式将服务器沙箱的运行状态恢复至崩溃前的运行状态，但在此不做限定。

优选地，该装置还包括监测及接收模块和第二建立模块；监测及接收模块服务器沙箱的Task管理器监测到客户端沙箱中任一应用程序启动后，接收来自客户端沙箱中已启动的应用程序发送建立连接的第二请求；第二建立模块响应于第二请求，服务器沙箱的Task管理器建立与应用程序与的第二连接关系。

例如，服务器沙箱的Task管理器监测到终端设备的客户端沙箱运行环境中的应用程序App1和App2启动后，App1和App2进行自我初始化相关操作后分别向服务器沙箱的Task管理器发送建立连接的第二请求Request3和Request4，Task管理器响应于第二请求Request3和Request4，分别建立与App1和App2的第二连接关系。

优选地，服务器沙箱的Task管理器监测到客户端沙箱中任一应用程序启动后，还包括第二接收模块；第二接收模块基于已建立的第二连接关系，服务器沙箱的Task管理接收来自客户端沙箱中已启动的应用程序发送的Task数据表。

其中，Task数据表包括客户端操作系统中与已启动的应用程序相匹配的Activity组件的相关数据、以及与Activity组件相匹配的系统级别的Task信息。

例如，服务器沙箱的Task管理器监测到客户端沙箱运行环境中应用程序App1和App2启动后，终端设备Android操作系统的ActivityManager组件启动与应用程序App1和App2相匹配的Activity组件，如Activity组件1和Activity组件2，并分别建立与Activity组件1和Activity组件2相匹配的系统级别的Task信息；ActivityManager组件将Activity组件1和Activity组件2成功启动后，在Activity.onCreate回调通知中，App1将自身的Activity和Task数据保存到App1的Task表中，App2将自身的Activity和Task数据保存到App2的Task表中，随后，ActivityManager组件将该启动后的Activity组件1的相关数据和App1的Task信息存储至应用程序App1的Task数据表中，并将该启动后的Activity组件2的相关数据和App2的Task信息存储至应用程序App2的Task数据表中；随后基于已建立的服务器沙箱Task管理器与App1的第二连接关系，App1将自身的Task数据表发送至服务器沙箱Task管理器，基于已建立的服务器沙箱Task管理器与App2的第二连接关系，App2将自身的Task数据表发送至服务器沙箱Task管理器，服务器沙箱的Task即可管理接收来自客户端沙箱中已启动的应用程序App1和App2发送的其各自的Task数据表。

通过本实施例，在沙箱运行环境中，服务器沙箱Task管理器预先获取客户端沙箱运行的状态信息进行保存，以确保服务器沙箱运行环境崩溃后，能够获取到服务器沙箱崩溃前的运行状态信息，为后续服务器沙箱重启后将服务器沙箱的运行状态恢复至崩溃前的运行状态提供了必要的前提保障。

本领域技术人员可以了解到，Android系统中的资源包括ActivityManagerService(AMS)资源、PackageManagerService资源、Activity组件、Service组件、Broadcast Receiver组件和Content Provider组件等。在Android操作系统中，AMS不仅用于管理所有应用程序进程的Activity的生命周期，它同时也管理着系统的Service、Broadcast Receiver以及Content Provider等组件。Android应用程序的真正入口是Application类的onCreate方法，应用程序创建以后就会调用onCreate，随后查找对应的Activity并创建，以执行一列Task的生命周期，因此，通过Application类的onCreate方法可获取到应用程序自身的Activity和Task数据。

优选地，该装置还包括第三接收模块和第二恢复模块；第三接收模块当监测到服务器沙箱重启后，接收到来自客户端沙箱发送的客户端操作系统Task信息中与沙箱相关的Task信息；第二恢复模块基于接收到的客户端操作系统Task信息中与沙箱相关的Task信息、以及Task表中的相关数据，将服务器沙箱的运行状态恢复至崩溃前的运行状态。

例如，在客户端沙箱运行环境中运行应用程序App1和App2，基于已建立的服务器沙箱Task管理器与App1和App2的各自第二连接关系，App1和App2将各自的Task数据表发送至服务器沙箱Task管理器，随后，服务器沙箱运行环境崩溃，当服务器沙箱Task管理器监测到服务器沙箱重启后，获取终端设备Android操作系统Task信息中与客户端沙箱相关的App1和App2的Task基本信息，基于获取到的App1和App2的Task基本信息，以及服务器沙箱Task管理器中接收到App1和App2各自的Task数据表信息，通过预定的算法，如通过各个应用程序的Task数据表信息得到各自对应的活动组件坑位，以使得服务器沙箱能够顺利重启，并得到服务器沙箱崩溃前的运行状态使得重启后的服务器沙箱恢复至崩溃前的运行状态，以使得终端设备中的应用程序App1和App2运行状态能够与服务器沙箱崩溃前的运行状态保持一致，使得终端设备中的应用程序App1和App2能够正常运行。

需要说明的是，本领域技术人员可以理解，Android系统中应用程序的配置文件Androidmanafest.xml中，各个Activity的注册信息可以视为独立注册信息模块，视为“坑位”。沙箱中运行的应用程可以向Android系统预注册多个activity组件坑位；出于预留的目的而在客户端沙箱中应用程序的Androidmanifest.xml配置文件中可以设置多个活动组件注册信息，但这些注册信息所指向的活动组件的真实内容并未确定。Android系统中，通过沙箱启动一个应用程序的Activity，由于该Activity是未知的，故沙箱无法在安装配置文件时对该应用程序进行事先声明，应用程序中的Activity是无法直接启动的，因此，可以形象地在配置文件中预留注册信息的活动组件，并在该配置文件提供给系统进行安装之后形成的活动组件虚拟单位称之为活动组件坑位，最终通过坑来代替应用程序中的Activity启动。

需要说明的是，本发明实施例中虽会以特定的预定算法为例说明，但在此不做限定。

通过本实施例，通过获取到的客户端操作系统Task信息中与沙箱相关的Task信息、以及Task表中的相关数据，能够更加准确地将服务器沙箱的运行状态恢复至崩溃前的运行状态，以使得客户端沙箱中的应用程序能够正常运行。

本技术领域技术人员可以理解，本发明包括涉及用于执行本申请中所述操作中的一项或多项的设备。这些设备可以为所需的目的而专门设计和制造，或者也可以包括通用计算机中的已知设备。这些设备具有存储在其内的计算机程序，这些计算机程序选择性地激活或重构。这样的计算机程序可以被存储在设备(例如，计算机)可读介质中或者存储在适于存储电子指令并分别耦联到总线的任何类型的介质中，所述计算机可读介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随即存储器)、EPROM(Erasable Programmable Read-Only Memory，可擦写可编程只读存储器)、EEPROM(Electrically Erasable Programmable Read-Only Memory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，可读介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。

本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本发明公开的结构图和/或框图和/或流图的框或多个框中指定的方案。

本技术领域技术人员可以理解，本发明中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本发明中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本发明中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。