在早些時候,我們可以通過以下方法:
1.在service中重寫onStartCommand方法,這個方法有三個返回值, START_STICKY是service被kill掉後自動重啓
public int onStartCommand(Intent intent, int flags, int startId) {
return START_STICKY;
}
2. 配置Android:persistent=”true”
3. setForeground(true);
4. android:process=”com.xxx.xxxservice”配置到單獨的進程中
以上的方法要麼只是提升service優先級或者存活率, 並不能解決被安全軟件強行殺死的問題.
要麼像第四種單獨的進程運行service在360老的版本是可以的,但是在360的比較新的版本中仍然會被殺死.
因此,我採用了一種別的方案. 另外再加上兩個類似一守護進程的Service, 分別檢查Service的運行狀態,註冊響應的廣播,對其進行守護,一旦發現沒有運行就將其啓動.我利用的系統廣播是Intent.ACTION_TIME_TICK,這個廣播每分鐘發送一次,我們可以每分鐘檢查一次Service的運行狀態,如果已經被結束了,就重新啓動Service。
它的優點就是間隔時間短而且非常穩定, 而其他的廣播並不能保證這一點,當然,在具體的應用中還是要根據需求使用, 結合其他廣播來保證自己的service一定會被重啓.
畢竟現在安全軟件是越來越厲害了,更新得也是非常頻繁. 有時間還是要看下還有沒有其他的方法,綜合幾種來使用.
1、 Intent.ACTION_TIME_TICK的使用
我們知道廣播的註冊有靜態註冊和動態註冊,但此係統廣播只能通過動態註冊的方式使用。即你不能通過在manifest.xml裏註冊的方式接收到這個廣播,只能在代碼裏通過
registerReceiver()方法註冊。
在This App extends Application 或者在service裏註冊廣播:
- IntentFilter filter = newIntentFilter(Intent.ACTION_TIME_TICK);
- MyBroadcastReceiver receiver = new MyBroadcastReceiver();
- registerReceiver(receiver, filter);
- boolean isServiceRunning = false;
- if (intent.getAction().equals(Intent.ACTION_TIME_TICK)) {
- //檢查Service狀態
- ActivityManager manager = (ActivityManager)AppApplication.getContext().getSystemService(Context.ACTIVITY_SERVICE);
- for (RunningServiceInfo service :manager.getRunningServices(Integer.MAX_VALUE)) {
- if(“so.xxxx.xxxxService”.equals(service.service.getClassName()))
- {
- isServiceRunning = true;
- }
- }
- if (!isServiceRunning) {
- Intent i = new Intent(context, xxxService.class);
- context.startService(i);
- }
- }
終極解決方案:
使用Jni,在 c端 fork進程,檢測Service是否存活,若Service已被殺死,則進行重啓Service.
至於檢測方式,可以輪詢獲取子進程Pid,若爲1, 則說明子進程被Init進程所領養,已經成爲了孤兒進程.
但是這種方式比較消耗電量,並且由於不同手機系統定製的改變,當應用被強制停止時,父進程並不一定被真正殺死,因此在一些特定機型上是無法通過此方式進行判斷. 這裏推薦使用liunx socket的方式進行類似心跳包的檢測,並且當觸發檢測Service是否被殺死之前,需要判斷應用是否已經被卸載,如果應用已經被卸載,則不再進行檢測Service行爲,直接調用exit(0)退出子進程,避免浪費系統資源和消耗電量.
注意: 目前在Android 5.0系統上會把fork出來的進程放到一個進程組裏, 當程序主進程掛掉後,也會把整個進程組殺掉,因此用fork的方式也無法在Android5.0及以上系統實現守護進程. 這個是系統層面的限制,當然也是爲了優化整個的系統環境,守護進程給手機帶來的體驗並不好