本發(fā)明涉及遠(yuǎn)程控制領(lǐng)域，具體涉及一種遠(yuǎn)程控制應(yīng)用程序啟動(dòng)的方法和系統(tǒng)。

背景技術(shù)：

在A(yíng)ndroid系統(tǒng)中啟動(dòng)應(yīng)用程序通常是通過(guò)手動(dòng)點(diǎn)擊的方式來(lái)啟動(dòng)應(yīng)用程序，如果本人不在的情況下是無(wú)法對(duì)應(yīng)用程序進(jìn)行啟動(dòng)的。但是在某些特殊使用情況下的時(shí)候，希望能夠遠(yuǎn)程啟動(dòng)應(yīng)用程序，比如遠(yuǎn)程測(cè)試或者其他應(yīng)用場(chǎng)景等。所以，為了能夠滿(mǎn)足特殊使用情況下，需要尋求一種能夠遠(yuǎn)程控制應(yīng)用程序啟動(dòng)的方法。

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

針對(duì)現(xiàn)有技術(shù)中存在的缺陷，本發(fā)明的目的在于提供一種不需要手動(dòng)點(diǎn)擊啟動(dòng)應(yīng)用程序，能夠遠(yuǎn)程控制應(yīng)用程序啟動(dòng)的方法。

為達(dá)到以上目的，本發(fā)明采取的技術(shù)方案是：一種遠(yuǎn)程控制應(yīng)用程序啟動(dòng)的方法，該方法包括以下步驟：

客戶(hù)端自定義靜態(tài)廣播接收器，并利用靜態(tài)廣播接收器接收Android系統(tǒng)啟動(dòng)的廣播信息；

建立客戶(hù)端與服務(wù)器之間的連接；

服務(wù)器下發(fā)啟動(dòng)應(yīng)用程序的控制命令至客戶(hù)端，所述啟動(dòng)應(yīng)用程序的控制命令包括需要啟動(dòng)的應(yīng)用程序的信息；以及

客戶(hù)端解析收到的控制命令，獲取需要啟動(dòng)的應(yīng)用程序的信息，并將需要啟動(dòng)的應(yīng)用程序的信息發(fā)送至靜態(tài)廣播接收器，由客戶(hù)端啟動(dòng)對(duì)應(yīng)的應(yīng)用程序。

在上述技術(shù)方案的基礎(chǔ)上，所述客戶(hù)端自定義靜態(tài)廣播接收器，并利用靜態(tài)廣播接收器接收Android系統(tǒng)啟動(dòng)的廣播信息包括以下步驟：

自定義靜態(tài)廣播接收器類(lèi)和靜態(tài)廣播接收器；

過(guò)濾Android系統(tǒng)啟動(dòng)完成的廣播事件；

靜態(tài)廣播接收器繼承Android系統(tǒng)的廣播接受者類(lèi)；

重寫(xiě)靜態(tài)廣播接收器中的onReceive()方法；

Android系統(tǒng)將啟動(dòng)的廣播信息發(fā)送至重寫(xiě)的onReceive()方法中。

在上述技術(shù)方案的基礎(chǔ)上，所述客戶(hù)端與服務(wù)器建立連接后，所述客戶(hù)端定期發(fā)送心跳包至服務(wù)器。

在上述技術(shù)方案的基礎(chǔ)上，所述客戶(hù)端通過(guò)軟件開(kāi)發(fā)工具包提供的網(wǎng)絡(luò)通信方式與服務(wù)器建立連接。

在上述技術(shù)方案的基礎(chǔ)上，客戶(hù)端與服務(wù)器建立連接的步驟包括：

將服務(wù)器的網(wǎng)絡(luò)地址傳遞到URL中，使用URL的構(gòu)造函數(shù)得到一個(gè)URL對(duì)象；

建立客戶(hù)端和服務(wù)器之間的連接。

在上述技術(shù)方案的基礎(chǔ)上，所述服務(wù)器通過(guò)HTTP將JSON格式的控制命令傳遞給客戶(hù)端，所述控制命令包含需要啟動(dòng)的應(yīng)用程序的包名信息和協(xié)議擴(kuò)展項(xiàng)。

在上述技術(shù)方案的基礎(chǔ)上，所述客戶(hù)端啟動(dòng)對(duì)應(yīng)的應(yīng)用程序的步驟包括：

客戶(hù)端解析服務(wù)器下發(fā)的啟動(dòng)應(yīng)用程序的控制命令，得到需要啟動(dòng)的應(yīng)用程序的包名信息；

將需要啟動(dòng)的應(yīng)用程序的包名信息傳遞到Intent對(duì)象中；

靜態(tài)廣播接收器接收Intent對(duì)象，Android系統(tǒng)根據(jù)應(yīng)用程序的包名信息，啟動(dòng)對(duì)應(yīng)的應(yīng)用程序；

判斷應(yīng)用程序是否啟動(dòng)成功，若是，則返回成功狀態(tài)，若否，則拋出異常消息。

在上述技術(shù)方案的基礎(chǔ)上，所述客戶(hù)端通過(guò)FastJson解析服務(wù)器下發(fā)的啟動(dòng)應(yīng)用程序的控制命令。

在上述技術(shù)方案的基礎(chǔ)上，所述客戶(hù)端啟動(dòng)對(duì)應(yīng)的應(yīng)用程序的步驟還包括啟動(dòng)反饋步驟；所述啟動(dòng)反饋步驟包括；

若客戶(hù)端啟動(dòng)應(yīng)用程序成功，客戶(hù)端將啟動(dòng)成功的信息傳遞給服務(wù)器，服務(wù)器停止下發(fā)啟動(dòng)應(yīng)用程序的控制命令；

若客戶(hù)端啟動(dòng)應(yīng)用程序失敗，客戶(hù)端將啟動(dòng)失敗的信息傳遞給服務(wù)器，服務(wù)器重復(fù)下發(fā)啟動(dòng)應(yīng)用程序的控制命令，直至應(yīng)用程序啟動(dòng)成功或達(dá)到預(yù)設(shè)的重復(fù)下發(fā)次數(shù)，當(dāng)應(yīng)用程序啟動(dòng)成功，則服務(wù)器停止下發(fā)啟動(dòng)應(yīng)用程序的控制命令，若達(dá)到預(yù)設(shè)的重復(fù)下發(fā)次數(shù)，則服務(wù)器停止下發(fā)啟動(dòng)應(yīng)用程序的控制命令，并將失敗信息記錄在日志文件中。

與此同時(shí)本發(fā)明還提供一種不需要手動(dòng)點(diǎn)擊啟動(dòng)應(yīng)用程序，能夠遠(yuǎn)程控制應(yīng)用程序啟動(dòng)的系統(tǒng)。

為達(dá)到以上目的，本發(fā)明采取的技術(shù)方案是：

一種遠(yuǎn)程控制應(yīng)用程序啟動(dòng)的系統(tǒng)，其包括通過(guò)網(wǎng)絡(luò)相連接的客戶(hù)端和服務(wù)器，

所述客戶(hù)端包括靜態(tài)廣播接收器，所述靜態(tài)廣播接收器用于接收Android系統(tǒng)啟動(dòng)的廣播信息；

所述服務(wù)器下發(fā)啟動(dòng)應(yīng)用程序的控制命令至所述客戶(hù)端；同時(shí)，

所述客戶(hù)端解析所述控制命令，獲取需要啟動(dòng)的應(yīng)用程序的信息，并將需要啟動(dòng)的應(yīng)用程序的信息發(fā)送至靜態(tài)廣播接收器，客戶(hù)端在接收到需要啟動(dòng)的應(yīng)用程序的信息后啟動(dòng)相應(yīng)應(yīng)用程序。

與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)點(diǎn)在于：

(1)本發(fā)明中使用了靜態(tài)廣播的方式來(lái)進(jìn)行接受Android系統(tǒng)啟動(dòng)的消息，通過(guò)自定義靜態(tài)廣播接收器BootBroadcastReceiver能夠達(dá)到在不開(kāi)啟應(yīng)用的情況下就能夠接受到Android系統(tǒng)發(fā)送過(guò)來(lái)的廣播消息，于傳統(tǒng)的動(dòng)態(tài)廣播接收這個(gè)是一個(gè)最大的顯著特性。選擇自定義靜態(tài)廣播方式接收Android系統(tǒng)啟動(dòng)廣播，后續(xù)服務(wù)就能夠在A(yíng)ndroid系統(tǒng)啟動(dòng)后立刻進(jìn)行啟動(dòng)，無(wú)需人為手動(dòng)再次啟動(dòng)相關(guān)服務(wù)了。

(2)本發(fā)明中的下發(fā)協(xié)議中使用了擴(kuò)充字段extra，這個(gè)擴(kuò)充字段使得本協(xié)議能夠有更好的擴(kuò)充性，后續(xù)協(xié)議進(jìn)行升級(jí)的時(shí)候，能夠很好的兼容老版本的協(xié)議而不需要對(duì)客戶(hù)端和服務(wù)器進(jìn)行協(xié)議重寫(xiě)。大大提高了本協(xié)議設(shè)計(jì)的兼容性和擴(kuò)展性。

(3)本發(fā)明中增加了啟動(dòng)反饋步驟，如果啟動(dòng)失敗會(huì)進(jìn)行多次嘗試，這樣能夠大大的提升啟動(dòng)成功的概率。相比傳統(tǒng)的僅僅下發(fā)一次啟動(dòng)命令方式有更高的啟動(dòng)成功率。

附圖說(shuō)明

圖1為本發(fā)明中遠(yuǎn)程控制應(yīng)用程序啟動(dòng)的方法的流程圖；

圖2為本發(fā)明中遠(yuǎn)程控制應(yīng)用程序啟動(dòng)的系統(tǒng)的結(jié)構(gòu)框圖。

具體實(shí)施方式

以下結(jié)合附圖對(duì)本發(fā)明作進(jìn)一步詳細(xì)說(shuō)明。

參見(jiàn)圖1所示，本發(fā)明提供一種遠(yuǎn)程控制應(yīng)用程序啟動(dòng)的方法，該方法包括以下步驟：

S1.客戶(hù)端自定義靜態(tài)廣播接收器，并利用靜態(tài)廣播接收器接收Android系統(tǒng)啟動(dòng)的廣播信息；

其具體包括以下步驟：

自定義靜態(tài)廣播接收器類(lèi)com.android.test.BootBroadcastReceiver和靜態(tài)廣播接收器BootBroadcastReceiver；

過(guò)濾Android系統(tǒng)啟動(dòng)完成的廣播事件；

靜態(tài)廣播接收器BootBroadcastReceiver繼承Android系統(tǒng)的BroadcastReceiver廣播接受者類(lèi)；

重寫(xiě)靜態(tài)廣播接收器BootBroadcastReceiver中的onReceive()方法；

Android系統(tǒng)將啟動(dòng)的廣播信息發(fā)送至重寫(xiě)的onReceive()方法中。

在A(yíng)ndroid中廣播監(jiān)聽(tīng)分為2種方式，其一是靜態(tài)廣播監(jiān)聽(tīng)，其二是動(dòng)態(tài)廣播監(jiān)聽(tīng)，以下描述一下其不同點(diǎn)：

靜態(tài)廣播：

靜態(tài)注冊(cè)是常駐型，也就是當(dāng)應(yīng)用程序關(guān)閉后，如果有信息廣播來(lái)，程序也會(huì)被Android系統(tǒng)調(diào)用自動(dòng)運(yùn)行。也就是說(shuō)靜態(tài)廣播可以在應(yīng)用沒(méi)有被啟動(dòng)的時(shí)候進(jìn)行注冊(cè)，當(dāng)接受到廣播信息后應(yīng)用能夠接收到對(duì)應(yīng)的廣播信息。

動(dòng)態(tài)廣播：

動(dòng)態(tài)注冊(cè)廣播不是常駐型廣播，動(dòng)態(tài)廣播的注冊(cè)需要在activity的生命周期中進(jìn)行注冊(cè)，也就是說(shuō)當(dāng)activit啟動(dòng)的時(shí)候去注冊(cè)動(dòng)態(tài)廣播，當(dāng)activity銷(xiāo)毀的時(shí)候需要反注冊(cè)廣播，其中activity在android中表示android的一個(gè)界面，也就是動(dòng)態(tài)廣播需要在應(yīng)用打開(kāi)的情況下才能夠進(jìn)行注冊(cè)，應(yīng)用程序沒(méi)有被打開(kāi)的時(shí)候是無(wú)法進(jìn)行動(dòng)態(tài)廣播注冊(cè)的。

由于需要監(jiān)聽(tīng)Android系統(tǒng)的啟動(dòng)信息，在A(yíng)ndroid系統(tǒng)剛剛啟動(dòng)完成的時(shí)候的應(yīng)用程序是沒(méi)有啟動(dòng)的，所以動(dòng)態(tài)廣播無(wú)法使用。因此本發(fā)明選用靜態(tài)廣播的方式來(lái)進(jìn)行接受應(yīng)用程序的啟動(dòng)廣播信息。

在A(yíng)ndroid系統(tǒng)中監(jiān)聽(tīng)廣播需要注冊(cè)監(jiān)聽(tīng)廣播事件到系統(tǒng)接口中。只有注冊(cè)過(guò)廣播的監(jiān)聽(tīng)器才能收到特定的廣播信號(hào)。靜態(tài)廣播的監(jiān)聽(tīng)器注冊(cè)需要寫(xiě)在A(yíng)ndroidManifest.xml文件中，只有在A(yíng)ndroidManifest.xml文件中注冊(cè)過(guò)的靜態(tài)廣播才能夠接受到對(duì)應(yīng)的廣播信息。AndroidManifest.xml指的是Android應(yīng)用程序的清單描述文件，這個(gè)文件中記錄了Android的所有界面和廣播以及應(yīng)用所需的權(quán)限等信息。

在A(yíng)ndroid的清單文件AndroidManifest.xml文件中進(jìn)行廣播注冊(cè)，具體注冊(cè)方式是在A(yíng)ndroidManifest.xml添加注冊(cè)監(jiān)聽(tīng)的事件，具體添加內(nèi)容如下所示：

下面對(duì)注冊(cè)代碼進(jìn)行分析：

<receiver

android:name＝"com.android.test.BootBroadcastReceiver">：

Receiver標(biāo)簽表示Android系統(tǒng)的廣播接收器標(biāo)簽，這個(gè)標(biāo)簽標(biāo)表示接下來(lái)的信息是一個(gè)廣播接收器。

com.android.test.BootBroadcastReceiver是自定義的廣播接收器類(lèi)。而自定義的靜態(tài)廣播接收器BootBroadcastReceiver用于接受系統(tǒng)的啟動(dòng)廣播信息。

<intent-filter>：

這個(gè)標(biāo)簽標(biāo)示廣播的過(guò)濾標(biāo)簽，Android系統(tǒng)的廣播種類(lèi)非常多而決定接收Android系統(tǒng)的哪些廣播，是通過(guò)過(guò)濾標(biāo)簽來(lái)實(shí)現(xiàn)的，只有過(guò)濾標(biāo)簽中標(biāo)注的廣播信息才能夠進(jìn)行接受，如果當(dāng)前過(guò)濾標(biāo)間中沒(méi)有標(biāo)注的廣播信息是不會(huì)進(jìn)行接收的。

<action

android:name＝"android.intent.action.BOOT_COMPLETED"/>：

這個(gè)action標(biāo)簽表示需要過(guò)濾的廣播事件，具體事件內(nèi)容是android.intent.action.BOOT_COMPLETED，其中android.intent.action.BOOT_COMPLETED這個(gè)表示的是Android系統(tǒng)啟動(dòng)完成的事件。

通過(guò)上述方法的廣播注冊(cè)，自定義的靜態(tài)廣播接收器BootBroadcastReceiver就能夠接受到Android系統(tǒng)啟動(dòng)的廣播信息了。

接受廣播信息的處理：

自定義的靜態(tài)廣播接收器BootBroadcastReceiver類(lèi)需要繼承Android系統(tǒng)的BroadcastReceiver類(lèi)，Android系統(tǒng)用的BroadcastReceiver類(lèi)是一個(gè)專(zhuān)門(mén)用于系統(tǒng)接受廣播的類(lèi)，繼承BroadcastReceiver類(lèi)后，自定義的靜態(tài)廣播接收器BootBroadcastReceiver就具備廣播接收功能。

BootBroadcastReceiver繼承BroadcastReceiver后，重寫(xiě)其中的onReceive方法，重寫(xiě)onReceive方法后，自定義的靜態(tài)廣播接收器BootBroadcastReceiver便能接收到廣播消息。當(dāng)Android系統(tǒng)啟動(dòng)后系統(tǒng)就會(huì)將啟動(dòng)的廣播消息發(fā)送給自定義的靜態(tài)廣播接收器BootBroadcastReceiver中的onReceive方法中，這樣就能夠在onReceive方法中處理系統(tǒng)啟動(dòng)后的事情。

本發(fā)明中使用了靜態(tài)廣播的方式來(lái)進(jìn)行接受Android系統(tǒng)啟動(dòng)的消息，通過(guò)自定義靜態(tài)廣播接收器BootBroadcastReceiver能夠達(dá)到在不開(kāi)啟應(yīng)用的情況下就能夠接受到Android系統(tǒng)發(fā)送過(guò)來(lái)的廣播消息，于傳統(tǒng)的動(dòng)態(tài)廣播接收這個(gè)是一個(gè)最大的顯著特性。選擇自定義靜態(tài)廣播方式接收Android系統(tǒng)啟動(dòng)廣播，后續(xù)服務(wù)就能夠在A(yíng)ndroid系統(tǒng)啟動(dòng)后立刻進(jìn)行啟動(dòng)，無(wú)需人為手動(dòng)再次啟動(dòng)相關(guān)服務(wù)了。

S2.建立客戶(hù)端與服務(wù)器之間的連接；

建立客戶(hù)端與服務(wù)器之間的連接和包括以下步驟：

1.創(chuàng)建URL對(duì)象

URL表示統(tǒng)一資源定位符，用來(lái)唯一表示一個(gè)網(wǎng)絡(luò)地址，將服務(wù)器的網(wǎng)絡(luò)地址傳遞到URL中，使用URL的構(gòu)造函數(shù)來(lái)得到一個(gè)URL的URL對(duì)象。在后續(xù)建立和服務(wù)器的連接的時(shí)候是需要使用URL對(duì)象。

2.通過(guò)openConnection創(chuàng)建連接

通過(guò)調(diào)用URL對(duì)象中的openConnection函數(shù)，就能夠建立和服務(wù)器之間的連接。

但是建立連接后如果客戶(hù)端長(zhǎng)時(shí)間不和服務(wù)器進(jìn)行通信，那么就可能會(huì)造成通信超時(shí)導(dǎo)致客戶(hù)端和服務(wù)器的連接斷開(kāi)，為了保持連接不會(huì)斷開(kāi)，本發(fā)明中客戶(hù)端會(huì)定期發(fā)送心跳包保持和服務(wù)器的通信不斷開(kāi)。

由于HTTP通信中服務(wù)器會(huì)輪詢(xún)客戶(hù)端是否發(fā)送消息，服務(wù)器如果長(zhǎng)時(shí)間沒(méi)有收到客戶(hù)端回復(fù)的消息，服務(wù)器為了釋放該客戶(hù)端占用的資源會(huì)斷開(kāi)與客戶(hù)端的鏈接。如果服務(wù)器和客戶(hù)端斷開(kāi)了連接，那么以后客戶(hù)端就無(wú)法和服務(wù)端通信，如果想要繼續(xù)通信，客戶(hù)端必須重新建立連接。但是建立連接的這個(gè)過(guò)程是非常耗時(shí)的，為了解決這個(gè)問(wèn)題客戶(hù)端可以通過(guò)發(fā)送心跳解決。

此外，客戶(hù)端定期發(fā)送心跳包至服務(wù)器(心跳包的內(nèi)容攜帶客戶(hù)端的一些基本信息，比如客戶(hù)端mac地址，設(shè)備相關(guān)信息，手機(jī)號(hào)等，主要目的就是和服務(wù)器進(jìn)行一次通信操作)，即可保證客戶(hù)端與服務(wù)器之間定期進(jìn)行通信。此時(shí)，服務(wù)器會(huì)認(rèn)為客戶(hù)端一直需要服務(wù)，因而服務(wù)器不會(huì)斷開(kāi)與客戶(hù)端的連接。故采用心跳包傳輸后，能夠很好的保障客戶(hù)端和服務(wù)器的連接不斷開(kāi)。

本步驟中，客戶(hù)端通過(guò)軟件開(kāi)發(fā)工具包JDK提供的網(wǎng)絡(luò)通信方式與服務(wù)器建立連接。且客戶(hù)端會(huì)定期發(fā)送心跳包保持和服務(wù)器的通信不斷開(kāi)。此外，由于心跳包中攜帶了客戶(hù)端的基本信息，這樣服務(wù)器就能夠很好的判定客戶(hù)端是否在線(xiàn)，如果在線(xiàn)就可以通過(guò)http下發(fā)啟動(dòng)應(yīng)用程序的控制命令來(lái)對(duì)其進(jìn)行啟動(dòng)控制。

S3.服務(wù)器下發(fā)啟動(dòng)應(yīng)用程序的控制命令至客戶(hù)端；

由于有心跳的存在，所以服務(wù)器和客戶(hù)端之間的連接不會(huì)被斷開(kāi)，服務(wù)器可以向客戶(hù)端下發(fā)控制命令字，控制命令是JSON格式的，通過(guò)HTTP將控制命令傳遞給客戶(hù)端。其中JSON(Java Script Object Notation)是一種輕量級(jí)的數(shù)據(jù)交換格式，它基于ECMAScript的一個(gè)子集。

啟動(dòng)應(yīng)用下發(fā)協(xié)議：

HTTP傳遞過(guò)來(lái)的是一串JSON數(shù)據(jù)，JSON數(shù)據(jù)中包含了需要啟動(dòng)的應(yīng)用程序的信息，比如應(yīng)用程序的包名信息，JSON數(shù)據(jù)的具體內(nèi)容如下所示：

接下來(lái)對(duì)傳遞過(guò)來(lái)的JSON數(shù)據(jù)進(jìn)行相關(guān)的說(shuō)明；

Cmd：表示命令，本命令書(shū)用于啟動(dòng)應(yīng)用程序，所以值是startApp；

Package：需要啟動(dòng)的應(yīng)用的包名；

Extra：協(xié)議擴(kuò)展項(xiàng)，方便后期協(xié)議升級(jí)時(shí)使用，目前預(yù)留暫不使用。

由于本下發(fā)協(xié)議中使用了擴(kuò)充字段extra，這個(gè)擴(kuò)充字段使得本協(xié)議能夠有更好的擴(kuò)充性，后續(xù)協(xié)議進(jìn)行升級(jí)的時(shí)候，能夠很好的兼容老版本的協(xié)議而不需要對(duì)客戶(hù)端和服務(wù)器進(jìn)行協(xié)議重寫(xiě)。大大提高了本協(xié)議設(shè)計(jì)的兼容性和擴(kuò)展性。

S4.客戶(hù)端解析收到的控制命令，獲取需要啟動(dòng)的應(yīng)用程序的信息，并將需要啟動(dòng)的應(yīng)用程序的信息發(fā)送至靜態(tài)廣播接收器，由客戶(hù)端啟動(dòng)對(duì)應(yīng)的應(yīng)用程序。

客戶(hù)端收到服務(wù)器傳遞過(guò)來(lái)的啟動(dòng)應(yīng)用程序的JSON信息以后，客戶(hù)端使用通用的FastJson對(duì)該JSON信息進(jìn)行解析，解析后獲得該應(yīng)用程序的啟動(dòng)信息，啟動(dòng)信息包括應(yīng)用程序的包名信息。

在A(yíng)ndroid系統(tǒng)中啟動(dòng)一個(gè)應(yīng)用程序需要應(yīng)用程序的包名信息，因?yàn)閼?yīng)用程序包名的唯一性可以確定啟動(dòng)的是哪一個(gè)應(yīng)用程序。

在A(yíng)ndroid系統(tǒng)中啟動(dòng)應(yīng)用程序的方法是調(diào)用startActivity函數(shù)來(lái)啟動(dòng)，startActivity函數(shù)需要傳遞一個(gè)Intent對(duì)象進(jìn)去。

Intent對(duì)象在A(yíng)ndroid系統(tǒng)中是一個(gè)意圖對(duì)象，通過(guò)調(diào)用Intent中的setComponentName函數(shù)即可將需要啟動(dòng)的應(yīng)用程序的包名信息傳遞到Intent對(duì)象中。

靜態(tài)廣播接收器接收包含需要啟動(dòng)的應(yīng)用程序的包名信息的Intent對(duì)象后，調(diào)用startActivity(Intent)函數(shù)，告訴Android系統(tǒng)需要啟動(dòng)一個(gè)應(yīng)用程序，此時(shí)Android系統(tǒng)就會(huì)將需要啟動(dòng)的對(duì)應(yīng)的應(yīng)用程序進(jìn)行啟動(dòng)。如果應(yīng)用啟動(dòng)成功，那么startActivity函數(shù)將會(huì)返回成功狀態(tài)，如果應(yīng)用啟動(dòng)失敗那么startActivity會(huì)拋出異常消息出來(lái)。

故可以通過(guò)startActivity函數(shù)是否拋出異常消息來(lái)判定應(yīng)用是否啟動(dòng)成功。

為了提高客戶(hù)端啟動(dòng)應(yīng)用程序的成功率，本發(fā)明中的客戶(hù)端啟動(dòng)對(duì)應(yīng)的應(yīng)用程序的步驟還包括啟動(dòng)反饋步驟，其包括：

若客戶(hù)端啟動(dòng)應(yīng)用程序成功，客戶(hù)端將啟動(dòng)成功的信息傳遞給服務(wù)器，服務(wù)器停止下發(fā)啟動(dòng)應(yīng)用程序的控制命令；

若客戶(hù)端啟動(dòng)應(yīng)用程序失敗，客戶(hù)端將啟動(dòng)失敗的信息傳遞給服務(wù)器，服務(wù)器重復(fù)下發(fā)啟動(dòng)應(yīng)用程序的控制命令，直至應(yīng)用程序啟動(dòng)成功或達(dá)到預(yù)設(shè)的重復(fù)下發(fā)次數(shù)，當(dāng)應(yīng)用程序啟動(dòng)成功，則服務(wù)器停止下發(fā)啟動(dòng)應(yīng)用程序的控制命令，若達(dá)到預(yù)設(shè)的重復(fù)下發(fā)次數(shù)，則服務(wù)器停止下發(fā)啟動(dòng)應(yīng)用程序的控制命令，并將失敗信息記錄在日志文件中。服務(wù)器重復(fù)下發(fā)啟動(dòng)應(yīng)用程序的控制命令至客戶(hù)端的次數(shù)可以根據(jù)需要控制，本發(fā)明中為三次。

由于增加了啟動(dòng)反饋步驟，如果啟動(dòng)失敗會(huì)進(jìn)行多次嘗試，這樣能夠大大的提升啟動(dòng)成功的概率。相比傳統(tǒng)的僅僅下發(fā)一次啟動(dòng)命令方式有更高的啟動(dòng)成功率。

本發(fā)明還提供一種遠(yuǎn)程控制應(yīng)用程序啟動(dòng)的系統(tǒng)，其包括通過(guò)網(wǎng)絡(luò)相連接的客戶(hù)端和服務(wù)器?？蛻?hù)端包括靜態(tài)廣播接收器，靜態(tài)廣播接收器用于接收Android系統(tǒng)啟動(dòng)的廣播信息；服務(wù)器下發(fā)啟動(dòng)應(yīng)用程序的控制命令至所述客戶(hù)端；同時(shí)，客戶(hù)端解析控制命令，獲取需要啟動(dòng)的應(yīng)用程序的信息，并將需要啟動(dòng)的應(yīng)用程序的信息發(fā)送至靜態(tài)廣播接收器，客戶(hù)端在接收到需要啟動(dòng)的應(yīng)用程序的信息后啟動(dòng)相應(yīng)應(yīng)用程序。

本發(fā)明不局限于上述實(shí)施方式，對(duì)于本技術(shù)領(lǐng)域的普通技術(shù)人員來(lái)說(shuō)，在不脫離本發(fā)明原理的前提下，還可以做出若干改進(jìn)和潤(rùn)飾，這些改進(jìn)和潤(rùn)飾也視為本發(fā)明的保護(hù)范圍之內(nèi)。本說(shuō)明書(shū)中未作詳細(xì)描述的內(nèi)容屬于本領(lǐng)域?qū)I(yè)技術(shù)人員公知的現(xiàn)有技術(shù)。