Android SERVICE後臺服務程式的守護
在早些時候,我們可以通過在
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的執行狀態是現在要說明的,核心就是利用ANDROID的系統廣播,觸發自己的程式檢查Service的執行狀態,如果被殺掉,就再起來。
常用的有開機廣播,解鎖螢幕的廣播,電量變化等等, 其中解屏的廣播算比較頻繁的了,但是也並不能保證一定的頻率,尤其是在特定的時間裡(比如使用者睡覺的時候,使用者並不進行解鎖操作).而我們仍要做一些操作的時候,就沒有辦法了.
因此,我採用了一種別的方案. 另外再加上兩個類似一守護程式的Service, 分別檢查Service的執行狀態,註冊響應的廣播,對其進行守護,一旦發現沒有執行就將其啟動.
我利用的系統廣播是
Intent.ACTION_TIME_TICK,這個廣播每分鐘傳送一次,我們可以每分鐘檢查一次Service的執行狀態,如果已經被結束了,就重新啟動Service。
它的優點就是間隔時間短而且非常穩定, 而其他的廣播並不能保證這一點,當然,在具體的應用中還是要根據需求使用, 結合其他廣播來保證自己的service一定會被重啟.
畢竟現在安全軟體是越來越厲害了,更新得也是非常頻繁. 有時間還是要看下還有沒有其他的方法,綜合幾種來使用.
下邊就是具體的程式碼和注意事項了:1、 Intent.ACTION_TIME_TICK的使用
我們知道廣播的註冊有靜態註冊和動態註冊,但此係統廣播只能通過動態註冊的方式使用。即你不能通過在manifest.xml裡註冊的方式接收到這個廣播,只能在程式碼裡通過
registerReceiver()方法註冊。
在ThisApp extends Application 或者在service裡註冊廣播:
IntentFilter filter = newIntentFilter(Intent.ACTION_TIME_TICK);
MyBroadcastReceiver receiver = new MyBroadcastReceiver();
registerReceiver(receiver, filter);
在廣播接收器MyBroadcastReceiver extends BroadcastReceiver的onReceive裡
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及以上系統實現守護程式. 這個是系統層面的限制,當然也是為了優化整個的系統環境,守護程式給手機帶來的體驗並不好
具體見原始碼:
http://androidxref.com/5.0.0_r2/xref/frameworks/base/services/core/java/com/android/server/am/ProcessRecord.java
補:
Android5.0 以上目前已有人使用黑科技攻克,部分機型可能無法起到作用,但思路很值得借鑑,程式碼結構也不錯, 具體方案見:
https://github.com/Marswin/MarsDaemon
如有轉載,請宣告出處: 時之沙:
http://blog.csdn.net/t12x3456
相關文章
- Android入門教程 | 四大元件之Service(前臺服務,後臺服務)Android元件
- Linux 下後臺執行和按照守護程式方式後臺執行的坑Linux
- Golang 後臺守護程式佇列處理方式小結Golang佇列
- 守護程式
- Android低記憶體終止守護程式Android記憶體
- android native service編寫及兩個服務程式通訊Android
- Android中後臺的服務和多執行緒Android執行緒
- Node 程式守護
- 程式守護 supervisor
- Linux 守護程式Linux
- Android8.0 後臺服務保活的一種思路Android
- C# Windows Service 服務程式的編寫C#Windows
- Linux下的守護程式分析Linux
- 守護程式那些事
- Golang 程式守護 SupervisorGolang
- Python編寫守護程式程式Python
- 小程式成為本地生活服務的“功守道”
- Linux守護程式的啟動方法Linux
- 高效管理 Android 前臺服務Android
- PHP 編寫守護程式PHP
- PHP 實現守護程式PHP
- Linux守護程式及SystemdLinux
- 如何讓Android的service一直在後臺執行?Android
- Android8.0以上版本啟動後臺service報IllegalStateExceptionAndroidException
- nuxt.js實現服務端渲染ssr (一)(環境配置、 多環境開發、程式守護、服務端映象)UXJS服務端
- 使用 SWOOLE 實現程式的守護(二)
- 使用 swoole 實現程式的守護(三)
- 使用 SWOOLE 實現程式的守護(一)
- opentracker改造為daemon守護程式
- Windows守護程式簡單示例Windows
- Android後臺任務(HandlerThread、AsyncTask、IntentService)AndroidthreadIntent
- 仿掘金前臺 vue 服務端渲染(ssr)後臺 react (spa) 後臺服務是 koa 的一個專案Vue服務端React
- 華為雲釋出CodeArts Check程式碼檢查服務,守護軟體質量和安全
- Java程式碼加密支援Android App Bundle動態化框架,守護核心程式碼安全Java加密AndroidAPP框架
- 使用 PHP 自建穩定可靠的守護程式PHP
- 打造跨平臺.NET Core後臺服務
- 服務網格 Service Mesh
- 共享榮耀守護之旅!360漏洞響應平臺“億萬守護計劃“上線!
- rsync 守護程式備份報錯