本發(fā)明涉及計(jì)算機(jī)技術(shù)領(lǐng)域，具體而言，本發(fā)明涉及一種沙箱運(yùn)行環(huán)境的檢測(cè)方法，及一種沙箱運(yùn)行環(huán)境的檢測(cè)裝置。

背景技術(shù)：

隨著時(shí)代的發(fā)展，各種終端設(shè)備已成為人們生活中必不可少的工具，各種功能強(qiáng)大的終端操作系統(tǒng)及終端應(yīng)用程序不斷涌現(xiàn)，為用戶帶來了更加便捷的體驗(yàn)?，F(xiàn)有技術(shù)中，應(yīng)用程序在終端設(shè)備的系統(tǒng)環(huán)境中僅可以唯一的形式安裝并運(yùn)行，如對(duì)于一種即時(shí)通信類應(yīng)用程序，在一臺(tái)終端設(shè)備中僅可以安裝并運(yùn)行一個(gè)該即時(shí)通信類應(yīng)用程序，用戶僅可以通過唯一的賬號(hào)登錄并對(duì)其執(zhí)行相關(guān)操作。但是，隨著即時(shí)通信類應(yīng)用程序的普及，越來越多的用戶希望在一臺(tái)終端設(shè)備中通過多個(gè)賬號(hào)登錄一種即時(shí)通信類應(yīng)用程序以實(shí)現(xiàn)對(duì)不同好友信息的區(qū)分管理及交流?，F(xiàn)有技術(shù)中，利用沙箱技術(shù)，使得目標(biāo)應(yīng)用程序可實(shí)現(xiàn)原生應(yīng)用程序的全部功能及相應(yīng)服務(wù)，但是，由于Android設(shè)備種類繁多，品牌眾多，版本各異，分辨率不統(tǒng)一等等導(dǎo)致了Android系統(tǒng)的碎片越來越嚴(yán)重，從而使得沙箱難免會(huì)崩潰，一般情況下，只能對(duì)將沙箱所有已經(jīng)啟動(dòng)的應(yīng)用程序全部退出，再由用戶重啟沙箱，以重啟各個(gè)應(yīng)用程序。通過該方式對(duì)沙箱進(jìn)行重啟，用戶能感覺到沙箱的閃退過程，嚴(yán)重影響了用戶的使用體驗(yàn)。

因此，亟需一種沙箱運(yùn)行環(huán)境的檢測(cè)方法，使得用戶在無感知的狀態(tài)下，快速的重啟沙箱運(yùn)行環(huán)境。

技術(shù)實(shí)現(xiàn)要素：

為克服上述技術(shù)問題或者至少部分地解決上述技術(shù)問題，特提出以下技術(shù)方案：

本發(fā)明的實(shí)施例提出了一種沙箱運(yùn)行環(huán)境的檢測(cè)方法，沙箱由服務(wù)器沙箱及客戶端沙箱構(gòu)成，包括：

檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的建立連接的多個(gè)第一請(qǐng)求；

基于第一請(qǐng)求，服務(wù)器沙箱的Task管理器建立與客戶端沙箱中各個(gè)應(yīng)用程序的多個(gè)第一連接關(guān)系；

基于多個(gè)第一連接關(guān)系，服務(wù)器沙箱的Task管理器接收客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)；

基于Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)。

可選地，檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，還包括：

初始化服務(wù)器沙箱運(yùn)行環(huán)境以重啟服務(wù)器沙箱，并初始化服務(wù)器沙箱的Task管理器。

可選地，還包括：

服務(wù)器沙箱的Task管理器監(jiān)測(cè)到客戶端沙箱中任一應(yīng)用程序啟動(dòng)后，接收來自客戶端沙箱中已啟動(dòng)的應(yīng)用程序發(fā)送建立連接的第二請(qǐng)求；

響應(yīng)于第二請(qǐng)求，服務(wù)器沙箱的Task管理器建立與應(yīng)用程序與的第二連接關(guān)系。

可選地，服務(wù)器沙箱的Task管理器監(jiān)測(cè)到客戶端沙箱中任一應(yīng)用程序啟動(dòng)后，還包括：

基于已建立的第二連接關(guān)系，服務(wù)器沙箱的Task管理接收來自客戶端沙箱中已啟動(dòng)的應(yīng)用程序發(fā)送的Task數(shù)據(jù)表。

優(yōu)選地，Task數(shù)據(jù)表包括客戶端操作系統(tǒng)中與已啟動(dòng)的應(yīng)用程序相匹配的Activity組件的相關(guān)數(shù)據(jù)、以及與Activity組件相匹配的系統(tǒng)級(jí)別的Task信息。

可選地，還包括：

當(dāng)監(jiān)測(cè)到服務(wù)器沙箱重啟后，接收到來自客戶端沙箱發(fā)送的客戶端操作系統(tǒng)Task信息中與沙箱相關(guān)的Task信息；

基于接收到的客戶端操作系統(tǒng)Task信息中與沙箱相關(guān)的Task信息、以及Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)。

本發(fā)明的另一實(shí)施例提出了一種沙箱運(yùn)行環(huán)境的檢測(cè)裝置，沙箱由服務(wù)器沙箱及客戶端沙箱構(gòu)成，包括：

檢測(cè)及發(fā)送模塊，用于檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的建立連接的多個(gè)第一請(qǐng)求；

第一建立模塊，用于基于第一請(qǐng)求，服務(wù)器沙箱的Task管理器建立與客戶端沙箱中各個(gè)應(yīng)用程序的多個(gè)第一連接關(guān)系；

第一接收模塊，用于基于多個(gè)第一連接關(guān)系，服務(wù)器沙箱的Task管理器接收客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)；

第一恢復(fù)模塊，用于基于Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)。

可選地，檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，還包括：

初始化模塊，用于初始化服務(wù)器沙箱運(yùn)行環(huán)境以重啟服務(wù)器沙箱，并初始化服務(wù)器沙箱的Task管理器。

可選地，還包括：

監(jiān)測(cè)及接收模塊，用于服務(wù)器沙箱的Task管理器監(jiān)測(cè)到客戶端沙箱中任一應(yīng)用程序啟動(dòng)后，接收來自客戶端沙箱中已啟動(dòng)的應(yīng)用程序發(fā)送建立連接的第二請(qǐng)求；

第二建立模塊，用于響應(yīng)于第二請(qǐng)求，服務(wù)器沙箱的Task管理器建立與應(yīng)用程序與的第二連接關(guān)系。

可選地，服務(wù)器沙箱的Task管理器監(jiān)測(cè)到客戶端沙箱中任一應(yīng)用程序啟動(dòng)后，還包括：

第二接收模塊，用于基于已建立的第二連接關(guān)系，服務(wù)器沙箱的Task管理接收來自客戶端沙箱中已啟動(dòng)的應(yīng)用程序發(fā)送的Task數(shù)據(jù)表。

優(yōu)選地，Task數(shù)據(jù)表包括客戶端操作系統(tǒng)中與已啟動(dòng)的應(yīng)用程序相匹配的Activity組件的相關(guān)數(shù)據(jù)、以及與Activity組件相匹配的系統(tǒng)級(jí)別的Task信息。

可選地，還包括：

第三接收模塊，用于當(dāng)監(jiān)測(cè)到服務(wù)器沙箱重啟后，接收到來自客戶端沙箱發(fā)送的客戶端操作系統(tǒng)Task信息中與沙箱相關(guān)的Task信息；

第二恢復(fù)模塊，用于基于接收到的客戶端操作系統(tǒng)Task信息中與沙箱相關(guān)的Task信息、以及Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)。

本發(fā)明的實(shí)施例中，提出了一種沙箱運(yùn)行環(huán)境的檢測(cè)方案，檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的建立連接的多個(gè)第一請(qǐng)求，基于第一請(qǐng)求，服務(wù)器沙箱的Task管理器建立與客戶端沙箱中各個(gè)應(yīng)用程序的多個(gè)第一連接關(guān)系，實(shí)現(xiàn)了各個(gè)應(yīng)用程序與服務(wù)器沙箱的Task管理器之間的通信，以使得服務(wù)器沙箱的Task管理器能夠管理客戶端沙箱中各應(yīng)用程序的Task信息；基于多個(gè)第一連接關(guān)系，服務(wù)器沙箱的Task管理器接收客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)，為將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)提供了必要的前提保障；基于Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，實(shí)現(xiàn)了根據(jù)客戶端沙箱中各個(gè)應(yīng)用程序各自的Task表信息，在不影響用戶使用體驗(yàn)的前提下，實(shí)現(xiàn)了在用戶無感知的狀態(tài)下即可準(zhǔn)確快速地將服務(wù)器沙箱運(yùn)行環(huán)境恢復(fù)至崩潰前的運(yùn)行狀態(tài)，以使得用戶在客戶端沙箱運(yùn)行環(huán)境中能夠平滑地繼續(xù)正常使用各應(yīng)用程序，提高了用戶的使用體驗(yàn)，進(jìn)一步地，通過沙箱運(yùn)行環(huán)境能有效的對(duì)各應(yīng)用程序進(jìn)行權(quán)限的攔截、并對(duì)各應(yīng)用程序的行為進(jìn)行監(jiān)控等，在一定程度上能解決因安卓系統(tǒng)上存在的諸多漏洞所帶來的安全隱患問題。

本發(fā)明附加的方面和優(yōu)點(diǎn)將在下面的描述中部分給出，這些將從下面的描述中變得明顯，或通過本發(fā)明的實(shí)踐了解到。

附圖說明

本發(fā)明上述的和/或附加的方面和優(yōu)點(diǎn)從下面結(jié)合附圖對(duì)實(shí)施例的描述中將變得明顯和容易理解，其中：

圖1為本發(fā)明中一個(gè)實(shí)施例的沙箱運(yùn)行環(huán)境的檢測(cè)方法的流程圖；

圖2為本發(fā)明中一個(gè)優(yōu)選實(shí)施例的服務(wù)器沙箱運(yùn)行環(huán)境重啟后Task管理器恢復(fù)沙箱運(yùn)行環(huán)境的工作流程圖；

圖3為本發(fā)明中另一優(yōu)選實(shí)施例的服務(wù)器沙箱運(yùn)行環(huán)境崩潰前Task管理器的工作流程圖；

圖4為本發(fā)明中另一優(yōu)選實(shí)施例的沙箱運(yùn)行環(huán)境的檢測(cè)裝置的結(jié)構(gòu)示意圖。

具體實(shí)施方式

下面詳細(xì)描述本發(fā)明的實(shí)施例，所述實(shí)施例的示例在附圖中示出，其中自始至終相同或類似的標(biāo)號(hào)表示相同或類似的元件或具有相同或類似功能的元件。下面通過參考附圖描述的實(shí)施例是示例性的，僅用于解釋本發(fā)明，而不能解釋為對(duì)本發(fā)明的限制。

本技術(shù)領(lǐng)域技術(shù)人員可以理解，除非特意聲明，這里使用的單數(shù)形式“一”、“一個(gè)”、“所述”和“該”也可包括復(fù)數(shù)形式。應(yīng)該進(jìn)一步理解的是，本發(fā)明的說明書中使用的措辭“包括”是指存在所述特征、整數(shù)、步驟、操作、元件和/或組件，但是并不排除存在或添加一個(gè)或多個(gè)其他特征、整數(shù)、步驟、操作、元件、組件和/或它們的組。應(yīng)該理解，當(dāng)我們稱元件被“連接”或“耦接”到另一元件時(shí)，它可以直接連接或耦接到其他元件，或者也可以存在中間元件。此外，這里使用的“連接”或“耦接”可以包括無線連接或無線耦接。這里使用的措辭“和/或”包括一個(gè)或更多個(gè)相關(guān)聯(lián)的列出項(xiàng)的全部或任一單元和全部組合。

本技術(shù)領(lǐng)域技術(shù)人員可以理解，除非另外定義，這里使用的所有術(shù)語(包括技術(shù)術(shù)語和科學(xué)術(shù)語)，具有與本發(fā)明所屬領(lǐng)域中的普通技術(shù)人員的一般理解相同的意義。還應(yīng)該理解的是，諸如通用字典中定義的那些術(shù)語，應(yīng)該被理解為具有與現(xiàn)有技術(shù)的上下文中的意義一致的意義，并且除非像這里一樣被特定定義，否則不會(huì)用理想化或過于正式的含義來解釋。

需要說明的是，本領(lǐng)域技術(shù)人員可以了解到，Android操作系統(tǒng)有其不同于其他操作系統(tǒng)的原理，Android為開發(fā)者提供四大組件，具體指Activity、Service、Broadcast Receiver以及Content Provider等組件。在日常應(yīng)用中Activity是與用戶交互的接口，它提供了一個(gè)用戶完成相關(guān)操作的窗口。當(dāng)在開發(fā)過程中創(chuàng)建Activity后，通過調(diào)用setContentView(View)方法來給該Activity指定一個(gè)布局界面，而這個(gè)界面就是提供給用戶交互的接口。Android系統(tǒng)中是通過Activity棧的方式來管理Activity的，而Activity自身則是通過生命周期的方法來管理自己的創(chuàng)建與銷毀。Activity棧是用戶一系列操作中所打開的多個(gè)Activity，按顯示順序組織成的一個(gè)堆棧，最先打開的Activity位于最底部，最后打開的在頂端，只有頂端的Activity才是可見的，退出頂端Activity后堆棧中下一個(gè)Activity變?yōu)轫敹?，該Activity方可見。

Android沙箱的本質(zhì)是為了實(shí)現(xiàn)不同應(yīng)用程序和進(jìn)程之間的互相隔離，即在默認(rèn)情況下，應(yīng)用程序沒有權(quán)限訪問系統(tǒng)資源或其它應(yīng)用程序的資源。每個(gè)應(yīng)用程序和系統(tǒng)進(jìn)程都被分配唯一并且固定的User Id(用戶標(biāo)識(shí)信息)，該uid與內(nèi)核層進(jìn)程的uid相對(duì)應(yīng)，同時(shí)，每個(gè)應(yīng)用程序在各自獨(dú)立的Dalvik虛擬機(jī)(用于Android平臺(tái)的虛擬機(jī))中運(yùn)行，擁有獨(dú)立的地址空間和資源。運(yùn)行于Dalvik虛擬機(jī)中的進(jìn)程必須依托內(nèi)核層Linux進(jìn)程而存在，因此Android使用Dalvik虛擬機(jī)和Linux的文件訪問控制來實(shí)現(xiàn)沙箱機(jī)制，任何應(yīng)用程序如果想要訪問系統(tǒng)資源或者其它應(yīng)用程序的資源必須在自己的manifest文件(它屬于AndroidManifest.xml文件，每一個(gè)應(yīng)用程序都要有一個(gè)manifest文件，它配置了應(yīng)用程序在Android系統(tǒng)上的基本信息)中進(jìn)行聲明權(quán)限或者共享uid。應(yīng)用程序進(jìn)程之間，應(yīng)用程序與操作系統(tǒng)之間的安全性由Linux操作系統(tǒng)的標(biāo)準(zhǔn)進(jìn)程級(jí)安全機(jī)制實(shí)現(xiàn)。在默認(rèn)狀態(tài)下，應(yīng)用程序之間無法交互，運(yùn)行在進(jìn)程沙箱內(nèi)的應(yīng)用程序沒有被分配權(quán)限，無法訪問系統(tǒng)或資源。因此，無論是直接運(yùn)行于操作系統(tǒng)之上的應(yīng)用程序，還是運(yùn)行于Dalvik虛擬機(jī)的應(yīng)用程序都得到同樣的安全隔離與保護(hù)，被限制在各自“沙箱”內(nèi)的應(yīng)用程序互不干擾，對(duì)系統(tǒng)與其他應(yīng)用程序的損害可降至最低。

Android任務(wù)棧又稱為Task，它是一個(gè)棧結(jié)構(gòu)，具有后進(jìn)先出的特性，用于存放Activity組件。Task與Activity棧有些類似，每一個(gè)Task是一個(gè)Activity棧，Task將相關(guān)的Activity組合在一起，并以棧的方式進(jìn)行管理，在Android操作系統(tǒng)中，每個(gè)應(yīng)用程序一般情況擁有多個(gè)Task，通過系統(tǒng)管理各應(yīng)用的Task，以及沙箱運(yùn)行環(huán)境的相關(guān)Task，都將無法獲取到每個(gè)應(yīng)用對(duì)應(yīng)的各個(gè)Task，因此，本發(fā)明的實(shí)施例中，在終端設(shè)備的沙箱運(yùn)行環(huán)境中創(chuàng)建Task管理器，Task管理器提供可在沙箱中以獨(dú)立進(jìn)程對(duì)所有非沙箱Activity棧以Task形式進(jìn)行管理的服務(wù)。

圖1為本發(fā)明中一個(gè)實(shí)施例的沙箱運(yùn)行環(huán)境的檢測(cè)方法的流程圖。

本發(fā)明的實(shí)施例中，各步驟所執(zhí)行的內(nèi)容概述如下：步驟S1010：檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的建立連接的多個(gè)第一請(qǐng)求；步驟S1020：基于第一請(qǐng)求，服務(wù)器沙箱的Task管理器建立與客戶端沙箱中各個(gè)應(yīng)用程序的多個(gè)第一連接關(guān)系；步驟S1030：基于多個(gè)第一連接關(guān)系，服務(wù)器沙箱的Task管理器接收客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)；步驟S1040：基于Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)。

本發(fā)明的實(shí)施例中，提出了一種沙箱運(yùn)行環(huán)境的檢測(cè)方法，檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的建立連接的多個(gè)第一請(qǐng)求，基于第一請(qǐng)求，服務(wù)器沙箱的Task管理器建立與客戶端沙箱中各個(gè)應(yīng)用程序的多個(gè)第一連接關(guān)系，實(shí)現(xiàn)了各個(gè)應(yīng)用程序與服務(wù)器沙箱的Task管理器之間的通信，以使得服務(wù)器沙箱的Task管理器能夠管理客戶端沙箱中各應(yīng)用程序的Task信息；基于多個(gè)第一連接關(guān)系，服務(wù)器沙箱的Task管理器接收客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)，為將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)提供了必要的前提保障；基于Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，實(shí)現(xiàn)了根據(jù)客戶端沙箱中各個(gè)應(yīng)用程序各自的Task表信息，在不影響用戶使用體驗(yàn)的前提下，實(shí)現(xiàn)了在用戶無感知的狀態(tài)下即可準(zhǔn)確快速地將服務(wù)器沙箱運(yùn)行環(huán)境恢復(fù)至崩潰前的運(yùn)行狀態(tài)，以使得用戶在客戶端沙箱運(yùn)行環(huán)境中能夠平滑地繼續(xù)正常使用各應(yīng)用程序，提高了用戶的使用體驗(yàn)，進(jìn)一步地，通過沙箱運(yùn)行環(huán)境能有效的對(duì)各應(yīng)用程序進(jìn)行權(quán)限的攔截、并對(duì)各應(yīng)用程序的行為進(jìn)行監(jiān)控等，在一定程度上能解決因安卓系統(tǒng)上存在的諸多漏洞所帶來的安全隱患問題。以下針對(duì)各個(gè)步驟的具體實(shí)現(xiàn)做進(jìn)一步的說明：

步驟S1010：檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的建立連接的多個(gè)第一請(qǐng)求。

例如，在服務(wù)器端，當(dāng)檢測(cè)服務(wù)器沙箱運(yùn)行環(huán)境崩潰后，終端設(shè)備的客戶端沙箱中的各個(gè)應(yīng)用程序，如App1和App2，將接收到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息，隨后，基于預(yù)定的頻率，如每隔5分鐘，終端設(shè)備的客戶端沙箱中的應(yīng)用程序App1和App2分別向服務(wù)器沙箱的Task管理器發(fā)送建立連接的第一請(qǐng)求，參考圖2中的步驟B，相應(yīng)的，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中App1和App2發(fā)送的建立連接的多個(gè)第一請(qǐng)求。

優(yōu)選地，步驟S1010檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后還包括步驟S1050；步驟S1050：初始化服務(wù)器沙箱運(yùn)行環(huán)境以重啟服務(wù)器沙箱，并初始化服務(wù)器沙箱的Task管理器。

例如，在服務(wù)器端，當(dāng)檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰后，初始化服務(wù)器沙箱運(yùn)行環(huán)境以重啟沙箱，如聲明適當(dāng)?shù)膍anifest權(quán)限，以用于啟動(dòng)客戶端沙箱應(yīng)用程序時(shí)將其與其他受信任的應(yīng)用程序運(yùn)行在同一進(jìn)程中，從而共享對(duì)其數(shù)據(jù)和代碼的訪問等初始化操作；并初始化服務(wù)器沙箱的Task管理器，包括啟動(dòng)服務(wù)器沙箱的Task管理器，對(duì)服務(wù)器沙箱的Task管理器進(jìn)行初始化相關(guān)配置，初始化跟蹤終端設(shè)備客戶端沙箱中各應(yīng)用程序的Task運(yùn)行的相關(guān)數(shù)據(jù)結(jié)構(gòu)等操作。

步驟S1020：基于第一請(qǐng)求，服務(wù)器沙箱的Task管理器建立與客戶端沙箱中各個(gè)應(yīng)用程序的多個(gè)第一連接關(guān)系。

例如，服務(wù)器沙箱中的Task管理器響應(yīng)于客戶端沙箱中的應(yīng)用程序App1向服務(wù)器沙箱的Task管理器發(fā)送建立連接的第一請(qǐng)求Request1，建立服務(wù)器沙箱的Task管理器與客戶端沙箱中應(yīng)用程序App1的第一連接關(guān)系，同時(shí)，應(yīng)用程序App2向服務(wù)器沙箱的Task管理器發(fā)送建立連接的第一請(qǐng)求Request2，建立服務(wù)器沙箱的Task管理器與客戶端沙箱中應(yīng)用程序App2的第一連接關(guān)系，參考圖2中的步驟C。

步驟S1030：基于多個(gè)第一連接關(guān)系，服務(wù)器沙箱的Task管理器接收客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)。

例如，基于已建立的Task管理器與客戶端沙箱中應(yīng)用程序App1和App2各自的第一連接關(guān)系，App1和App2將各自的Task表中的相關(guān)數(shù)據(jù)發(fā)送至服務(wù)器沙箱Task管理器，服務(wù)器沙箱的Task管理器接收App1和App2發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)，參考圖2中的步驟D。

在本發(fā)明的實(shí)施例中，客戶端沙箱運(yùn)行環(huán)境中的各個(gè)應(yīng)用程序，各自維護(hù)一個(gè)Task表，由于Task將相關(guān)的Activity組合在一起，并以棧的方式進(jìn)行管理，因此Task表中記錄著各個(gè)Activity的相關(guān)信息，因此，獲取到各應(yīng)用程序的各自的各個(gè)Activity的相關(guān)信息即可獲取各個(gè)應(yīng)用程序的運(yùn)行相關(guān)信息。

步驟S1040：基于Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)。

例如，在終端設(shè)備的沙箱運(yùn)行環(huán)境中包括應(yīng)用程序App1和App2，基于應(yīng)用程序App1和App2各自的Task表中的相關(guān)數(shù)據(jù)，可獲取到應(yīng)用程序App1和App2各自的運(yùn)行狀態(tài)相關(guān)信息，隨后，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，以使得終端設(shè)備中的應(yīng)用程序App1和App2的行狀態(tài)能夠與服務(wù)器沙箱崩潰前的運(yùn)行狀態(tài)保持一致，使得終端設(shè)備中的應(yīng)用程序App1和App2能夠正常運(yùn)行。

需要說明的是，本發(fā)明的實(shí)施例中，可以通過服務(wù)器Task管理器將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，也可以通過服務(wù)器沙箱中的其他恢復(fù)程序?qū)⒎?wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，本發(fā)明的實(shí)施例中雖會(huì)以特定的恢復(fù)方式將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，但在此不做限定。

優(yōu)選地，該方法還包括步驟S1060和步驟S1070；步驟S1060：服務(wù)器沙箱的Task管理器監(jiān)測(cè)到客戶端沙箱中任一應(yīng)用程序啟動(dòng)后，接收來自客戶端沙箱中已啟動(dòng)的應(yīng)用程序發(fā)送建立連接的第二請(qǐng)求；步驟S1070：響應(yīng)于第二請(qǐng)求，服務(wù)器沙箱的Task管理器建立與應(yīng)用程序與的第二連接關(guān)系。

例如，服務(wù)器沙箱的Task管理器監(jiān)測(cè)到終端設(shè)備的客戶端沙箱運(yùn)行環(huán)境中的應(yīng)用程序App1和App2啟動(dòng)后，App1和App2進(jìn)行自我初始化相關(guān)操作后分別向服務(wù)器沙箱的Task管理器發(fā)送建立連接的第二請(qǐng)求Request3和Request4，Task管理器響應(yīng)于第二請(qǐng)求Request3和Request4，分別建立與App1和App2的第二連接關(guān)系，參考圖1中的步驟A和B。

優(yōu)選地，步驟S1060中服務(wù)器沙箱的Task管理器監(jiān)測(cè)到客戶端沙箱中任一應(yīng)用程序啟動(dòng)后，還包括步驟S1080；步驟S1080：基于已建立的第二連接關(guān)系，服務(wù)器沙箱的Task管理接收來自客戶端沙箱中已啟動(dòng)的應(yīng)用程序發(fā)送的Task數(shù)據(jù)表。

其中，Task數(shù)據(jù)表包括客戶端操作系統(tǒng)中與已啟動(dòng)的應(yīng)用程序相匹配的Activity組件的相關(guān)數(shù)據(jù)、以及與Activity組件相匹配的系統(tǒng)級(jí)別的Task信息。

例如，服務(wù)器沙箱的Task管理器監(jiān)測(cè)到客戶端沙箱運(yùn)行環(huán)境中應(yīng)用程序App1和App2啟動(dòng)后，終端設(shè)備Android操作系統(tǒng)的ActivityManager組件啟動(dòng)與應(yīng)用程序App1和App2相匹配的Activity組件，如Activity組件1和Activity組件2，并分別建立與Activity組件1和Activity組件2相匹配的系統(tǒng)級(jí)別的Task信息，參考圖3中的步驟D；ActivityManager組件將Activity組件1和Activity組件2成功啟動(dòng)后，在Activity.onCreate回調(diào)通知中，App1將自身的Activity和Task數(shù)據(jù)保存到App1的Task表中，App2將自身的Activity和Task數(shù)據(jù)保存到App2的Task表中，隨后，ActivityManager組件將該啟動(dòng)后的Activity組件1的相關(guān)數(shù)據(jù)和App1的Task信息存儲(chǔ)至應(yīng)用程序App1的Task數(shù)據(jù)表中，并將該啟動(dòng)后的Activity組件2的相關(guān)數(shù)據(jù)和App2的Task信息存儲(chǔ)至應(yīng)用程序App2的Task數(shù)據(jù)表中，參考圖3中的步驟E；隨后基于已建立的服務(wù)器沙箱Task管理器與App1的第二連接關(guān)系，App1將自身的Task數(shù)據(jù)表發(fā)送至服務(wù)器沙箱Task管理器，基于已建立的服務(wù)器沙箱Task管理器與App2的第二連接關(guān)系，App2將自身的Task數(shù)據(jù)表發(fā)送至服務(wù)器沙箱Task管理器，參考圖3中的步驟F，服務(wù)器沙箱的Task即可管理接收來自客戶端沙箱中已啟動(dòng)的應(yīng)用程序App1和App2發(fā)送的其各自的Task數(shù)據(jù)表。

通過本實(shí)施例，在沙箱運(yùn)行環(huán)境中，服務(wù)器沙箱Task管理器預(yù)先獲取客戶端沙箱運(yùn)行的狀態(tài)信息進(jìn)行保存，以確保服務(wù)器沙箱運(yùn)行環(huán)境崩潰后，能夠獲取到服務(wù)器沙箱崩潰前的運(yùn)行狀態(tài)信息，為后續(xù)服務(wù)器沙箱重啟后將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)提供了必要的前提保障。

本領(lǐng)域技術(shù)人員可以了解到，Android系統(tǒng)中的資源包括ActivityManagerService(AMS)資源、PackageManagerService資源、Activity組件、Service組件、Broadcast Receiver組件和Content Provider組件等。在Android操作系統(tǒng)中，AMS不僅用于管理所有應(yīng)用程序進(jìn)程的Activity的生命周期，它同時(shí)也管理著系統(tǒng)的Service、Broadcast Receiver以及Content Provider等組件。Android應(yīng)用程序的真正入口是Application類的onCreate方法，應(yīng)用程序創(chuàng)建以后就會(huì)調(diào)用onCreate，隨后查找對(duì)應(yīng)的Activity并創(chuàng)建，以執(zhí)行一列Task的生命周期，因此，通過Application類的onCreate方法可獲取到應(yīng)用程序自身的Activity和Task數(shù)據(jù)。

優(yōu)選地，該方法還包括步驟S1090和步驟S1100；步驟S1090：當(dāng)監(jiān)測(cè)到服務(wù)器沙箱重啟后，接收到來自客戶端沙箱發(fā)送的客戶端操作系統(tǒng)Task信息中與沙箱相關(guān)的Task信息；步驟S1100：基于接收到的客戶端操作系統(tǒng)Task信息中與沙箱相關(guān)的Task信息、以及Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)。

例如，在客戶端沙箱運(yùn)行環(huán)境中運(yùn)行應(yīng)用程序App1和App2，基于已建立的服務(wù)器沙箱Task管理器與App1和App2的各自第二連接關(guān)系，App1和App2將各自的Task數(shù)據(jù)表發(fā)送至服務(wù)器沙箱Task管理器，隨后，服務(wù)器沙箱運(yùn)行環(huán)境崩潰，當(dāng)服務(wù)器沙箱Task管理器監(jiān)測(cè)到服務(wù)器沙箱重啟后，獲取終端設(shè)備Android操作系統(tǒng)Task信息中與客戶端沙箱相關(guān)的App1和App2的Task基本信息，基于獲取到的App1和App2的Task基本信息，以及服務(wù)器沙箱Task管理器中接收到App1和App2各自的Task數(shù)據(jù)表信息，通過預(yù)定的算法，如通過各個(gè)應(yīng)用程序的Task數(shù)據(jù)表信息得到各自對(duì)應(yīng)的活動(dòng)組件坑位，以使得服務(wù)器沙箱能夠順利重啟，并得到服務(wù)器沙箱崩潰前的運(yùn)行狀態(tài)使得重啟后的服務(wù)器沙箱恢復(fù)至崩潰前的運(yùn)行狀態(tài)，以使得終端設(shè)備中的應(yīng)用程序App1和App2運(yùn)行狀態(tài)能夠與服務(wù)器沙箱崩潰前的運(yùn)行狀態(tài)保持一致，使得終端設(shè)備中的應(yīng)用程序App1和App2能夠正常運(yùn)行。

需要說明的是，本領(lǐng)域技術(shù)人員可以理解，Android系統(tǒng)中應(yīng)用程序的配置文件Androidmanafest.xml中，各個(gè)Activity的注冊(cè)信息可以視為獨(dú)立注冊(cè)信息模塊，視為“坑位”。沙箱中運(yùn)行的應(yīng)用程可以向Android系統(tǒng)預(yù)注冊(cè)多個(gè)activity組件坑位；出于預(yù)留的目的而在客戶端沙箱中應(yīng)用程序的Androidmanifest.xml配置文件中可以設(shè)置多個(gè)活動(dòng)組件注冊(cè)信息，但這些注冊(cè)信息所指向的活動(dòng)組件的真實(shí)內(nèi)容并未確定。Android系統(tǒng)中，通過沙箱啟動(dòng)一個(gè)應(yīng)用程序的Activity，由于該Activity是未知的，故沙箱無法在安裝配置文件時(shí)對(duì)該應(yīng)用程序進(jìn)行事先聲明，應(yīng)用程序中的Activity是無法直接啟動(dòng)的，因此，可以形象地在配置文件中預(yù)留注冊(cè)信息的活動(dòng)組件，并在該配置文件提供給系統(tǒng)進(jìn)行安裝之后形成的活動(dòng)組件虛擬單位稱之為活動(dòng)組件坑位，最終通過坑來代替應(yīng)用程序中的Activity啟動(dòng)。

需要說明的是，本發(fā)明實(shí)施例中雖會(huì)以特定的預(yù)定算法為例說明，但在此不做限定。

通過本實(shí)施例，通過獲取到的客戶端操作系統(tǒng)Task信息中與沙箱相關(guān)的Task信息、以及Task表中的相關(guān)數(shù)據(jù)，能夠更加準(zhǔn)確地將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，以使得客戶端沙箱中的應(yīng)用程序能夠正常運(yùn)行。

圖4為本發(fā)明中另一優(yōu)選實(shí)施例的沙箱運(yùn)行環(huán)境的檢測(cè)裝置的結(jié)構(gòu)示意圖。

本發(fā)明的實(shí)施例中，各模塊所執(zhí)行的內(nèi)容概述如下：檢測(cè)及發(fā)送模塊410檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的建立連接的多個(gè)第一請(qǐng)求；第一建立模塊420基于第一請(qǐng)求，服務(wù)器沙箱的Task管理器建立與客戶端沙箱中各個(gè)應(yīng)用程序的多個(gè)第一連接關(guān)系；第一接收模塊430基于多個(gè)第一連接關(guān)系，服務(wù)器沙箱的Task管理器接收客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)；第一恢復(fù)模塊440基于Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)。

本發(fā)明的實(shí)施例中，提出了一種沙箱運(yùn)行環(huán)境的檢測(cè)裝置，檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的建立連接的多個(gè)第一請(qǐng)求，基于第一請(qǐng)求，服務(wù)器沙箱的Task管理器建立與客戶端沙箱中各個(gè)應(yīng)用程序的多個(gè)第一連接關(guān)系，實(shí)現(xiàn)了各個(gè)應(yīng)用程序與服務(wù)器沙箱的Task管理器之間的通信，以使得服務(wù)器沙箱的Task管理器能夠管理客戶端沙箱中各應(yīng)用程序的Task信息；基于多個(gè)第一連接關(guān)系，服務(wù)器沙箱的Task管理器接收客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)，為將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)提供了必要的前提保障；基于Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，實(shí)現(xiàn)了根據(jù)客戶端沙箱中各個(gè)應(yīng)用程序各自的Task表信息，在不影響用戶使用體驗(yàn)的前提下，實(shí)現(xiàn)了在用戶無感知的狀態(tài)下即可準(zhǔn)確快速地將服務(wù)器沙箱運(yùn)行環(huán)境恢復(fù)至崩潰前的運(yùn)行狀態(tài)，以使得用戶在客戶端沙箱運(yùn)行環(huán)境中能夠平滑地繼續(xù)正常使用各應(yīng)用程序，提高了用戶的使用體驗(yàn)，進(jìn)一步地，通過沙箱運(yùn)行環(huán)境能有效的對(duì)各應(yīng)用程序進(jìn)行權(quán)限的攔截、并對(duì)各應(yīng)用程序的行為進(jìn)行監(jiān)控等，在一定程度上能解決因安卓系統(tǒng)上存在的諸多漏洞所帶來的安全隱患問題。以下針對(duì)各個(gè)模塊的具體實(shí)現(xiàn)做進(jìn)一步的說明：

檢測(cè)及發(fā)送模塊410檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的建立連接的多個(gè)第一請(qǐng)求。

例如，在服務(wù)器端，當(dāng)檢測(cè)服務(wù)器沙箱運(yùn)行環(huán)境崩潰后，終端設(shè)備的客戶端沙箱中的各個(gè)應(yīng)用程序，如App1和App2，將接收到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息，隨后，基于預(yù)定的頻率，如每隔5分鐘，終端設(shè)備的客戶端沙箱中的應(yīng)用程序App1和App2分別向服務(wù)器沙箱的Task管理器發(fā)送建立連接的第一請(qǐng)求，相應(yīng)的，服務(wù)器沙箱的Task管理器接收來自客戶端沙箱中App1和App2發(fā)送的建立連接的多個(gè)第一請(qǐng)求。

優(yōu)選地，檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰的通知消息后還包括初始化模塊；初始化模塊初始化服務(wù)器沙箱運(yùn)行環(huán)境以重啟服務(wù)器沙箱，并初始化服務(wù)器沙箱的Task管理器。

例如，在服務(wù)器端，當(dāng)檢測(cè)到服務(wù)器沙箱運(yùn)行環(huán)境崩潰后，初始化服務(wù)器沙箱運(yùn)行環(huán)境以重啟沙箱，如聲明適當(dāng)?shù)膍anifest權(quán)限，以用于啟動(dòng)客戶端沙箱應(yīng)用程序時(shí)將其與其他受信任的應(yīng)用程序運(yùn)行在同一進(jìn)程中，從而共享對(duì)其數(shù)據(jù)和代碼的訪問等初始化操作；并初始化服務(wù)器沙箱的Task管理器，包括啟動(dòng)服務(wù)器沙箱的Task管理器，對(duì)服務(wù)器沙箱的Task管理器進(jìn)行初始化相關(guān)配置，初始化跟蹤終端設(shè)備客戶端沙箱中各應(yīng)用程序的Task運(yùn)行的相關(guān)數(shù)據(jù)結(jié)構(gòu)等操作。

第一建立模塊420基于第一請(qǐng)求，服務(wù)器沙箱的Task管理器建立與客戶端沙箱中各個(gè)應(yīng)用程序的多個(gè)第一連接關(guān)系。

例如，服務(wù)器沙箱中的Task管理器響應(yīng)于客戶端沙箱中的應(yīng)用程序App1向服務(wù)器沙箱的Task管理器發(fā)送建立連接的第一請(qǐng)求Request1，建立服務(wù)器沙箱的Task管理器與客戶端沙箱中應(yīng)用程序App1的第一連接關(guān)系，同時(shí)，應(yīng)用程序App2向服務(wù)器沙箱的Task管理器發(fā)送建立連接的第一請(qǐng)求Request2，建立服務(wù)器沙箱的Task管理器與客戶端沙箱中應(yīng)用程序App2的第一連接關(guān)系。

第一接收模塊430基于多個(gè)第一連接關(guān)系，服務(wù)器沙箱的Task管理器接收客戶端沙箱中各個(gè)應(yīng)用程序發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)。

例如，基于已建立的Task管理器與客戶端沙箱中應(yīng)用程序App1和App2各自的第一連接關(guān)系，App1和App2將各自的Task表中的相關(guān)數(shù)據(jù)發(fā)送至服務(wù)器沙箱Task管理器，服務(wù)器沙箱的Task管理器接收App1和App2發(fā)送的其各自的Task表中的相關(guān)數(shù)據(jù)。

在本發(fā)明的實(shí)施例中，客戶端沙箱運(yùn)行環(huán)境中的各個(gè)應(yīng)用程序，各自維護(hù)一個(gè)Task表，由于Task將相關(guān)的Activity組合在一起，并以棧的方式進(jìn)行管理，因此Task表中記錄著各個(gè)Activity的相關(guān)信息，因此，獲取到各應(yīng)用程序的各自的各個(gè)Activity的相關(guān)信息即可獲取各個(gè)應(yīng)用程序的運(yùn)行相關(guān)信息。

第一恢復(fù)模塊440基于Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)。

例如，在終端設(shè)備的沙箱運(yùn)行環(huán)境中包括應(yīng)用程序App1和App2，基于應(yīng)用程序App1和App2各自的Task表中的相關(guān)數(shù)據(jù)，可獲取到應(yīng)用程序App1和App2各自的運(yùn)行狀態(tài)相關(guān)信息，隨后，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，以使得終端設(shè)備中的應(yīng)用程序App1和App2的行狀態(tài)能夠與服務(wù)器沙箱崩潰前的運(yùn)行狀態(tài)保持一致，使得終端設(shè)備中的應(yīng)用程序App1和App2能夠正常運(yùn)行。

需要說明的是，本發(fā)明的實(shí)施例中，可以通過服務(wù)器Task管理器將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，也可以通過服務(wù)器沙箱中的其他恢復(fù)程序?qū)⒎?wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，本發(fā)明的實(shí)施例中雖會(huì)以特定的恢復(fù)方式將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，但在此不做限定。

優(yōu)選地，該裝置還包括監(jiān)測(cè)及接收模塊和第二建立模塊；監(jiān)測(cè)及接收模塊服務(wù)器沙箱的Task管理器監(jiān)測(cè)到客戶端沙箱中任一應(yīng)用程序啟動(dòng)后，接收來自客戶端沙箱中已啟動(dòng)的應(yīng)用程序發(fā)送建立連接的第二請(qǐng)求；第二建立模塊響應(yīng)于第二請(qǐng)求，服務(wù)器沙箱的Task管理器建立與應(yīng)用程序與的第二連接關(guān)系。

例如，服務(wù)器沙箱的Task管理器監(jiān)測(cè)到終端設(shè)備的客戶端沙箱運(yùn)行環(huán)境中的應(yīng)用程序App1和App2啟動(dòng)后，App1和App2進(jìn)行自我初始化相關(guān)操作后分別向服務(wù)器沙箱的Task管理器發(fā)送建立連接的第二請(qǐng)求Request3和Request4，Task管理器響應(yīng)于第二請(qǐng)求Request3和Request4，分別建立與App1和App2的第二連接關(guān)系。

優(yōu)選地，服務(wù)器沙箱的Task管理器監(jiān)測(cè)到客戶端沙箱中任一應(yīng)用程序啟動(dòng)后，還包括第二接收模塊；第二接收模塊基于已建立的第二連接關(guān)系，服務(wù)器沙箱的Task管理接收來自客戶端沙箱中已啟動(dòng)的應(yīng)用程序發(fā)送的Task數(shù)據(jù)表。

其中，Task數(shù)據(jù)表包括客戶端操作系統(tǒng)中與已啟動(dòng)的應(yīng)用程序相匹配的Activity組件的相關(guān)數(shù)據(jù)、以及與Activity組件相匹配的系統(tǒng)級(jí)別的Task信息。

例如，服務(wù)器沙箱的Task管理器監(jiān)測(cè)到客戶端沙箱運(yùn)行環(huán)境中應(yīng)用程序App1和App2啟動(dòng)后，終端設(shè)備Android操作系統(tǒng)的ActivityManager組件啟動(dòng)與應(yīng)用程序App1和App2相匹配的Activity組件，如Activity組件1和Activity組件2，并分別建立與Activity組件1和Activity組件2相匹配的系統(tǒng)級(jí)別的Task信息；ActivityManager組件將Activity組件1和Activity組件2成功啟動(dòng)后，在Activity.onCreate回調(diào)通知中，App1將自身的Activity和Task數(shù)據(jù)保存到App1的Task表中，App2將自身的Activity和Task數(shù)據(jù)保存到App2的Task表中，隨后，ActivityManager組件將該啟動(dòng)后的Activity組件1的相關(guān)數(shù)據(jù)和App1的Task信息存儲(chǔ)至應(yīng)用程序App1的Task數(shù)據(jù)表中，并將該啟動(dòng)后的Activity組件2的相關(guān)數(shù)據(jù)和App2的Task信息存儲(chǔ)至應(yīng)用程序App2的Task數(shù)據(jù)表中；隨后基于已建立的服務(wù)器沙箱Task管理器與App1的第二連接關(guān)系，App1將自身的Task數(shù)據(jù)表發(fā)送至服務(wù)器沙箱Task管理器，基于已建立的服務(wù)器沙箱Task管理器與App2的第二連接關(guān)系，App2將自身的Task數(shù)據(jù)表發(fā)送至服務(wù)器沙箱Task管理器，服務(wù)器沙箱的Task即可管理接收來自客戶端沙箱中已啟動(dòng)的應(yīng)用程序App1和App2發(fā)送的其各自的Task數(shù)據(jù)表。

通過本實(shí)施例，在沙箱運(yùn)行環(huán)境中，服務(wù)器沙箱Task管理器預(yù)先獲取客戶端沙箱運(yùn)行的狀態(tài)信息進(jìn)行保存，以確保服務(wù)器沙箱運(yùn)行環(huán)境崩潰后，能夠獲取到服務(wù)器沙箱崩潰前的運(yùn)行狀態(tài)信息，為后續(xù)服務(wù)器沙箱重啟后將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)提供了必要的前提保障。

本領(lǐng)域技術(shù)人員可以了解到，Android系統(tǒng)中的資源包括ActivityManagerService(AMS)資源、PackageManagerService資源、Activity組件、Service組件、Broadcast Receiver組件和Content Provider組件等。在Android操作系統(tǒng)中，AMS不僅用于管理所有應(yīng)用程序進(jìn)程的Activity的生命周期，它同時(shí)也管理著系統(tǒng)的Service、Broadcast Receiver以及Content Provider等組件。Android應(yīng)用程序的真正入口是Application類的onCreate方法，應(yīng)用程序創(chuàng)建以后就會(huì)調(diào)用onCreate，隨后查找對(duì)應(yīng)的Activity并創(chuàng)建，以執(zhí)行一列Task的生命周期，因此，通過Application類的onCreate方法可獲取到應(yīng)用程序自身的Activity和Task數(shù)據(jù)。

優(yōu)選地，該裝置還包括第三接收模塊和第二恢復(fù)模塊；第三接收模塊當(dāng)監(jiān)測(cè)到服務(wù)器沙箱重啟后，接收到來自客戶端沙箱發(fā)送的客戶端操作系統(tǒng)Task信息中與沙箱相關(guān)的Task信息；第二恢復(fù)模塊基于接收到的客戶端操作系統(tǒng)Task信息中與沙箱相關(guān)的Task信息、以及Task表中的相關(guān)數(shù)據(jù)，將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)。

例如，在客戶端沙箱運(yùn)行環(huán)境中運(yùn)行應(yīng)用程序App1和App2，基于已建立的服務(wù)器沙箱Task管理器與App1和App2的各自第二連接關(guān)系，App1和App2將各自的Task數(shù)據(jù)表發(fā)送至服務(wù)器沙箱Task管理器，隨后，服務(wù)器沙箱運(yùn)行環(huán)境崩潰，當(dāng)服務(wù)器沙箱Task管理器監(jiān)測(cè)到服務(wù)器沙箱重啟后，獲取終端設(shè)備Android操作系統(tǒng)Task信息中與客戶端沙箱相關(guān)的App1和App2的Task基本信息，基于獲取到的App1和App2的Task基本信息，以及服務(wù)器沙箱Task管理器中接收到App1和App2各自的Task數(shù)據(jù)表信息，通過預(yù)定的算法，如通過各個(gè)應(yīng)用程序的Task數(shù)據(jù)表信息得到各自對(duì)應(yīng)的活動(dòng)組件坑位，以使得服務(wù)器沙箱能夠順利重啟，并得到服務(wù)器沙箱崩潰前的運(yùn)行狀態(tài)使得重啟后的服務(wù)器沙箱恢復(fù)至崩潰前的運(yùn)行狀態(tài)，以使得終端設(shè)備中的應(yīng)用程序App1和App2運(yùn)行狀態(tài)能夠與服務(wù)器沙箱崩潰前的運(yùn)行狀態(tài)保持一致，使得終端設(shè)備中的應(yīng)用程序App1和App2能夠正常運(yùn)行。

需要說明的是，本領(lǐng)域技術(shù)人員可以理解，Android系統(tǒng)中應(yīng)用程序的配置文件Androidmanafest.xml中，各個(gè)Activity的注冊(cè)信息可以視為獨(dú)立注冊(cè)信息模塊，視為“坑位”。沙箱中運(yùn)行的應(yīng)用程可以向Android系統(tǒng)預(yù)注冊(cè)多個(gè)activity組件坑位；出于預(yù)留的目的而在客戶端沙箱中應(yīng)用程序的Androidmanifest.xml配置文件中可以設(shè)置多個(gè)活動(dòng)組件注冊(cè)信息，但這些注冊(cè)信息所指向的活動(dòng)組件的真實(shí)內(nèi)容并未確定。Android系統(tǒng)中，通過沙箱啟動(dòng)一個(gè)應(yīng)用程序的Activity，由于該Activity是未知的，故沙箱無法在安裝配置文件時(shí)對(duì)該應(yīng)用程序進(jìn)行事先聲明，應(yīng)用程序中的Activity是無法直接啟動(dòng)的，因此，可以形象地在配置文件中預(yù)留注冊(cè)信息的活動(dòng)組件，并在該配置文件提供給系統(tǒng)進(jìn)行安裝之后形成的活動(dòng)組件虛擬單位稱之為活動(dòng)組件坑位，最終通過坑來代替應(yīng)用程序中的Activity啟動(dòng)。

需要說明的是，本發(fā)明實(shí)施例中雖會(huì)以特定的預(yù)定算法為例說明，但在此不做限定。

通過本實(shí)施例，通過獲取到的客戶端操作系統(tǒng)Task信息中與沙箱相關(guān)的Task信息、以及Task表中的相關(guān)數(shù)據(jù)，能夠更加準(zhǔn)確地將服務(wù)器沙箱的運(yùn)行狀態(tài)恢復(fù)至崩潰前的運(yùn)行狀態(tài)，以使得客戶端沙箱中的應(yīng)用程序能夠正常運(yùn)行。

本技術(shù)領(lǐng)域技術(shù)人員可以理解，本發(fā)明包括涉及用于執(zhí)行本申請(qǐng)中所述操作中的一項(xiàng)或多項(xiàng)的設(shè)備。這些設(shè)備可以為所需的目的而專門設(shè)計(jì)和制造，或者也可以包括通用計(jì)算機(jī)中的已知設(shè)備。這些設(shè)備具有存儲(chǔ)在其內(nèi)的計(jì)算機(jī)程序，這些計(jì)算機(jī)程序選擇性地激活或重構(gòu)。這樣的計(jì)算機(jī)程序可以被存儲(chǔ)在設(shè)備(例如，計(jì)算機(jī))可讀介質(zhì)中或者存儲(chǔ)在適于存儲(chǔ)電子指令并分別耦聯(lián)到總線的任何類型的介質(zhì)中，所述計(jì)算機(jī)可讀介質(zhì)包括但不限于任何類型的盤(包括軟盤、硬盤、光盤、CD-ROM、和磁光盤)、ROM(Read-Only Memory，只讀存儲(chǔ)器)、RAM(Random Access Memory，隨即存儲(chǔ)器)、EPROM(Erasable Programmable Read-Only Memory，可擦寫可編程只讀存儲(chǔ)器)、EEPROM(Electrically Erasable Programmable Read-Only Memory，電可擦可編程只讀存儲(chǔ)器)、閃存、磁性卡片或光線卡片。也就是，可讀介質(zhì)包括由設(shè)備(例如，計(jì)算機(jī))以能夠讀的形式存儲(chǔ)或傳輸信息的任何介質(zhì)。

本技術(shù)領(lǐng)域技術(shù)人員可以理解，可以用計(jì)算機(jī)程序指令來實(shí)現(xiàn)這些結(jié)構(gòu)圖和/或框圖和/或流圖中的每個(gè)框以及這些結(jié)構(gòu)圖和/或框圖和/或流圖中的框的組合。本技術(shù)領(lǐng)域技術(shù)人員可以理解，可以將這些計(jì)算機(jī)程序指令提供給通用計(jì)算機(jī)、專業(yè)計(jì)算機(jī)或其他可編程數(shù)據(jù)處理方法的處理器來實(shí)現(xiàn)，從而通過計(jì)算機(jī)或其他可編程數(shù)據(jù)處理方法的處理器來執(zhí)行本發(fā)明公開的結(jié)構(gòu)圖和/或框圖和/或流圖的框或多個(gè)框中指定的方案。

本技術(shù)領(lǐng)域技術(shù)人員可以理解，本發(fā)明中已經(jīng)討論過的各種操作、方法、流程中的步驟、措施、方案可以被交替、更改、組合或刪除。進(jìn)一步地，具有本發(fā)明中已經(jīng)討論過的各種操作、方法、流程中的其他步驟、措施、方案也可以被交替、更改、重排、分解、組合或刪除。進(jìn)一步地，現(xiàn)有技術(shù)中的具有與本發(fā)明中公開的各種操作、方法、流程中的步驟、措施、方案也可以被交替、更改、重排、分解、組合或刪除。

以上所述僅是本發(fā)明的部分實(shí)施方式，應(yīng)當(dāng)指出，對(duì)于本技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進(jìn)和潤飾，這些改進(jìn)和潤飾也應(yīng)視為本發(fā)明的保護(hù)范圍。