android不被殺死

『壹』 怎麼讓 Android 程序一直後台運行，像 QQ 一樣不被殺死

可以開啟保護模式。開發者選項里一般就有

『貳』 怎麼讓Android程序一直後台運行，像QQ一樣不被殺死

1、首先要保證你的程序一直在於後台運行，也就是所謂和守護程序一樣，而且在任何認為kill和系統內存回收kill後，保證重啟。
2、獲取系統內部資源。
3、上報策略，間隔時間上報還是按月按天上報。
4、監測網路，當網路開啟的時候第一時間上報數據。
5、伺服器連接。
對於以上問題的解決：
1、利用廣播BroadcastReceiver監聽，當系統啟動時啟動服務service，監聽的action是
android.intent.action.BOOT_COMPLETED，當服務被kill時在onDestroy()再次啟動服務，在
onStartCommand()中 設置 flags = START_STICKY;return
super.onStartCommand(intent, flags, startId)，保證服務重啟。
2、利用getPackageManager(),getInstalledPackages(),getApplicationInfo()來獲取系統安裝數據。
3、上報策略可以每天（時間間隔24小時），但是不是很准確，一般按日上報不做時間間隔這樣個人認為比較准確。
4、檢測開啟網路上報數據，還是利用廣播BroadcastReceiver監聽，監聽action為android.net.conn.CONNECTIVITY_CHANGE，當發現網路開啟時就觸發數據上報。
5、伺服器連接，如果你了解java熟悉java企業級開發，那麼你對httpclient並不陌生，很幸運的是android sdk已經集成了httpclient，那我們伺服器連接首選它了。

以上是我做的解決方案，你是否有更好的替代品，希望我只是拋了塊磚頭，後面你繼續。。。。

service被系統異常kill掉後回重啟。有以下值：

onStartCommand有三種返回值：
START_STICKY：sticky的意思是「粘性的」。使用這個返回值時，我們啟動的服務跟應用程序」粘」在一起，如果在執行完onStartCommand後，服務被異常kill掉，系統會自動重啟該服務。當再次啟動服務時，傳入的第一個參數將為null;
START_NOT_STICKY：「非粘性的」。使用這個返回值時，如果在執行完onStartCommand後，服務被異常kill掉，系統不會自動重啟該服務。
START_REDELIVER_INTENT：重傳Intent。使用這個返回值時，如果在執行完onStartCommand後，服務被異常kill掉，系統會自動重啟該服務，並將Intent的值傳入。

『叄』 android 怎麼保證服務不被殺死

1: 正常 stop service的時候會執行生命周期的 onDestory() 可以在銷毀方法中執行再次 startService();

2: 當收到內存影響的時候，out-of-memory killer會銷毀掉一些優先順序低的app：
相較於/data/app下的應用，放在/system/app下的應用享受更多的特權，
比如若在其Manifest.xml文件中設置persistent屬性為true，
則可使其免受out-of-memory killer的影響。
如應用程序'Phone'的AndroidManifest.xml文件：
<application android:name="PhoneApp"
android:persistent="true"
android:label="@string/dialerIconLabel"
android:icon="@drawable/ic_launcher_phone">
...
</application>
設置後app提升為系統核心級別，任何情況下不會被kill掉,
settings->applications裡面也會屏蔽掉stop操作,再次情況下，發現4.1.2的程序在設置裡面的應用裡面，程序沒有禁止掉停止。
在此情況下還要應用上1的重新啟動。

3: force stop service 的時候，則不執行 onDestory(),
還有一種情況是 第三方任務管理器清理掉整個程序的時候；

google 管方就有，ForegroundService 前台服務，讓服務一直以前台任務的方式運行，可以在service 的oncreate來實現前台服務， 通過這個方法必須發送一個通知欄，讓用戶知道服務在運行。我們可以把service修改成前台運行方式，只不過讓通知notification不去顯示就OK了。

『肆』 android後台服務保持，不被殺死

作者：閉關寫代碼
鏈接：https://www.hu.com/question/29826231/answer/71207109
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。

強烈建議不要這么做，不僅僅從用戶角度考慮，作為Android開發者也有責任去維護Android的生態環境。現在很多Android開發工程師，主力機居然是iPhone而不是Android設備，感到相當悲哀。
從技術角度概括一下現在普遍的防殺方法

Service設置成START_STICKY，kill 後會被重啟（等待5秒左右），重傳Intent，保持與重啟前一樣
通過 startForeground將進程設置為前台進程，做前台服務，優先順序和前台應用一個級別，除非在系統內存非常缺，否則此進程不會被 kill

雙進程Service：讓2個進程互相保護，其中一個Service被清理後，另外沒被清理的進程可以立即重啟進程
QQ黑科技:在應用退到後台後，另起一個只有 1 像素的頁面停留在桌面上，讓自己保持前台狀態，保護自己不被後台清理工具殺死
在已經root的設備下，修改相應的許可權文件，將App偽裝成系統級的應用（Android4.0系列的一個漏洞，已經確認可行）
Android系統中當前進程(Process)fork出來的子進程，被系統認為是兩個不同的進程。當父進程被殺死的時候，子進程仍然可以存活，並不受影響。鑒於目前提到的在Android-Service層做雙守護都會失敗，我們可以fork出c進程，多進程守護。死循環在那檢查是否還存在，具體的思路如下（Android5.0以下可行）
用C編寫守護進程(即子進程)，守護進程做的事情就是循環檢查目標進程是否存在，不存在則啟動它。
在NDK環境中將1中編寫的C代碼編譯打包成可執行文件(BUILD_EXECUTABLE)。
主進程啟動時將守護進程放入私有目錄下，賦予可執行許可權，啟動它即可。
聯系廠商，加入白名單
------------------------------------------------------
TIP: 面對各種流氓軟體後台常駐問題，建議使用「綠色守護」來解決，可是殺掉那些第三方清理工具難以清除的後台程序

『伍』 想讓android應用常駐後台，不被殺死，各位大神有什麼高招

方法： 對於一個service，可以首先把它設為在前台運行： public void MyService.onCreate() { super.onCreate(); Notification notification = new Notification(android.R.drawable.my_service_icon, "my_service_name", System.currentTimeMillis()); PendingIntent p_intent = PendingIntent.getActivity(this, 0, new Intent(this, MyMainActivity.class), 0); notification.setLatestEventInfo(this, "MyServiceNotification, "MyServiceNotification is Running!", p_intent); Log.d(TAG, String.format("notification = %s", notification)); startForeground(0x1982, notification); // notification ID: 0x1982, you can name it as you will. } 重要設置------------------------------- 相較於/data/app下的應用，放在/system/app下的應用享受更多的特權，比如若在其Manifest.xml文件中設置persistent屬性為true，則可使其免受out-of-memory killer的影響。如應用程序'Phone'的AndroidManifest.xml文件： <application android:name="PhoneApp" android:persistent="true" android:label="@string/dialerIconLabel" android:icon="@drawable/ic_launcher_phone"> ... </application> 設置後app提升為系統核心級別，任何情況下不會被kill掉, settings->applications裡面也會屏蔽掉stop操作。 這樣設置前的log: Proc #19: adj=svc /B 4067b028 255:com.xxx.xxx/10001 (started-services) # cat /proc/255/oom_adj 設置後的log: PERS #19: adj=core /F 406291f0 155:com.xxx.xxx/10001 (fixed) # cat /proc/155/oom_adj -12 # 這是CORE_SERVER_ADJ 註：init進程的oom_adj為-16（即SYSTEM_ADJ）： cat /proc/1/oom_adj Android相關部分分析： 在文件frameworks/base/services/java/com/android/server/am/ActivityManagerService.java中有以下的代碼： final ProcessRecord addAppLocked(ApplicationInfo info) { ProcessRecord app = getProcessRecordLocked(info.processName, info.uid); if (app == null) { app = newProcessRecordLocked(null, info, null); mProcessNames.put(info.processName, info.uid, app); updateLruProcessLocked(app, true, true); } if ((info.flags&(ApplicationInfo.FLAG_SYSTEMApplicationInfo.FLAG_PERSISTENT)) == (ApplicationInfo.FLAG_SYSTEMApplicationInfo.FLAG_PERSISTENT)) { app.persistent = true; app.maxAdj = CORE_SERVER_ADJ; // 這個常數值為-12。 } if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) { mPersistentStartingProcesses.add(app); startProcessLocked(app, "added application", app.processName); } return app; } 可見要想成為core service （即app.maxAdj = CORE_SERVER_ADJ(-12)），應用程序需要FLAG_SYSTEM和FLAG_PERSISTENT兩個標志，FLAG_SYSTEM指的是應用位於/system/app下，FLAG_PERSISTENT就是指persistent屬性。 而對於frameworks/base/services/java/com/android/server/SystemServer.java，則調用 ActivityManagerService.setSystemProcess(); 把自己的 app.maxAdj 設置成SYSTEM_ADJ，即-16。 原理： Android中的進程是託管的，當系統進程空間緊張的時候，會依照優先順序自動進行進程的回收。由此帶來三個問題： 1） 回收規則: 什麼時候回收與回收哪一個？ 2） 避免誤殺: 如何阻止被回收？ 3） 數據恢復與保存: 被回收了怎麼辦？ Android將進程分為6個等級,它們按優先順序順序由高到低依次是: 1.前台進程( FOREGROUND_APP) 2.可視進程(VISIBLE_APP ) 3. 次要服務進程(SECONDARY_SERVER ) 4.後台進程 (HIDDEN_APP) 5.內容供應節點(CONTENT_PROVIDER) 6.空進程(EMPTY_APP) 特徵： 1.如果一個進程裡面同時包含service和可視的activity，那麼這個進程應該歸於可視進程，而不是service進程。 2.另外，如果其他進程依賴於它的話，一個進程的等級可以提高。例如，一個A進程里的service被綁定到B進程里的組件上，進程A將總被認為至少和B進程一樣重要。 3.系統中的phone服務被劃分到前台進程而不是次要服務進程. 在android中，進程的oom_adj值也就代表了它的優先順序。oom_adj值越高代表該進程優先順序越低。文件/init.rc中有以下屬性設置： setprop ro.FOREGROUND_APP_ADJ 0 setprop ro.VISIBLE_APP_ADJ 1 setprop ro.SECONDARY_SERVER_ADJ 2 setprop ro.HIDDEN_APP_MIN_ADJ 7 setprop ro.CONTENT_PROVIDER_ADJ 14 setprop ro.EMPTY_APP_ADJ 15 /init.rc中，將PID為1的進程(init進程)的oom_adj設置為SYSTEM_ADJ(-16): # Set init its forked children's oom_adj. write /proc/1/oom_adj -16 查看本機設置： cat /sys/mole/lowmemorykiller/parameters/adj 0,1,2,7,14,15 回收時機： 文件/init.rc中: setprop ro.FOREGROUND_APP_MEM 1536 // 6M setprop ro.VISIBLE_APP_MEM 2048 // 8M setprop ro.SECONDARY_SERVER_MEM 4096 // 16M setprop ro.HIDDEN_APP_MEM 5120 // 20M setprop ro.CONTENT_PROVIDER_MEM 5632 // 22.4M setprop ro.EMPTY_APP_MEM 6144 // 24M 這些數字也就是對應的內存閾值，一旦低於該值，Android便開始按順序關閉相應等級的進程。 注意這些數字的單位是page： 1 page = 4 kB。所以上面的六個數字對應的就是(MB): 6,8,16,20,22,24。 查看現在的內存閾值設置： cat /sys/mole/lowmemorykiller/parameters/minfree 要想重新設置該值（對應不同的需求）: echo "1536,2048,4096,5120,15360,23040">/sys/mole/lowmemorykiller/parameters/minfree 這樣當可用內存低於90MB的時候便開始殺死"空進程"，而當可用內存低於60MB的時候才開始殺死"內容供應節點"類進程。 具體的回收實現在ActivityManagerService.java中的函數trimApplications()： 1.首先移除package已被卸載的無用進程； 2.基於進程當前狀態，更新oom_adj值，然後進行以下操作： 1) 移除沒有activity在運行的進程; 2) 如果AP已經保存了所有的activity狀態，結束這個AP。 3. 最後，如果目前還是有很多activities 在運行，那麼移除那些activity狀態已經保存好的activity。 更新oom_adj的值： 在ActivityManagerService.java文件的ComputeOomAdjLocked() 中計算出進程的oom_adj，例如: if (app == TOP_APP) { // The last app on the list is the foreground app. adj = FOREGROUND_APP_ADJ; app.adjType = "top-activity"; } Android kernel中的low memory killer Android的Low Memory Killer根據需要（當系統內存短缺時）殺死進程釋放其內存，源代碼在kernel/drivers/misc/lowmemorykiller.c中。簡單說，就是尋找一個最合適的進程殺死，從而釋放它佔用的內存。 最合適的進程是: • oom_adj越大 • 佔用物理內存越多 一旦一個進程被選中，內核會發送SIGKILL信號將之殺死： for_each_process(p) { …… if(selected == NULL p->oomkilladj > selected->oomkilladj (p->oomkilladj == selected->oomkilladj && tasksize > selected_tasksize)) { selected = p; } } if(selected != NULL) { force_sig(SIGKILL, selected); } 查看LRU列表：adb shell mpsys activity 當activitydemo在前台時： 包含Service的進程的優先順序比較高，在computeOomAdjLocked中將其分為了兩小類: static final int MAX_SERVICE_INACTIVITY = 30*60*1000; if (now < (s.lastActivity+MAX_SERVICE_INACTIVITY)) { if (adj > SECONDARY_SERVER_ADJ) { adj = SECONDARY_SERVER_ADJ; app.adjType = "started-services"; app.hidden = false; } } if (adj > SECONDARY_SERVER_ADJ) { app.adjType = "started-bg-services"; } 完全讓進程不被kill是不可能的，我們可以通過一些操作，使進程被kill的幾率變小： 1) 提高進程的優先順序: * 後台操作採用運行於前台的Service形式，因為一個運行著service的進程比一個運行著後台activity的等級高； * 按back鍵使得進程中的activity在後台運行而不是destory，需重載back按鍵(沒有任何activity在運行的進程優先被殺). * 依賴於其他優先順序高的進程； 2) 強制修改進程屬性： * 在進程中設置：setPersistent(true); * 在Manifest文件中設置（如上）。

『陸』 如何防止android app被kill

1.在service中重寫下面的方法，這個方法有三個返回值，START_STICKY是service被kill掉後自動重寫創建[代碼]java代碼：@(Intentintent,intflags,intstartId){returnSTART_STICKY;}----------------@(Intentintent,intflags,intstartId){//TODOAuto-generatedmethodstubLog.v("TrafficService","startCommand");flags=START_STICKY;returnsuper.onStartCommand(intent,flags,startId);//returnSTART_REDELIVER_INTENT;}2.在Service的onDestroy()中重啟Service.publicvoidonDestroy(){IntentlocalIntent=newIntent();localIntent.setClass(this,MyService.class);//銷毀時重新啟動Servicethis.startService(localIntent);}用 管家殺掉進程的時候，調用的是系統自帶的強制kill功能（即settings里的），在kill時，會將應用的整個進程停掉，當然包括service在內，如果在running里將service強制kill掉，顯示進程還在。不管是kill整個進程還是只kill掉進應用的service，都不會重新啟動service。不知道你是怎麼實現重啟的，實在是不解。在eclipse中，用stop按鈕kill掉進程的時候，倒是會重啟serviceKILL問題：1.settings中stopserviceonDestroy方法中，調用startService進行Service的重啟。2.settings中forcestop應用捕捉系統進行廣播（action為android.intent.action.PACKAGE_RESTARTED）3.藉助第三方應用kill掉runningtask提升service的優先順序service開機啟動今天我們主要來探討android怎麼讓一個service開機自動啟動功能的實現。Android手機在啟動的過程中會觸發一個StandardBroadcastAction，名字叫android.intent.action.BOOT_COMPLETED(記得只會觸發一次呀),在這里我們可以通過構建一個廣播接收者來接收這個這個action.下面我就來簡單寫以下實現的步驟：第一步：首先創建一個廣播接收者,重構其抽象方法onReceive(Contextcontext,Intentintent)，在其中啟動你想要啟動的Service或app。[代碼]java代碼：importandroid.content.BroadcastReceiver;importandroid.content.Context;importandroid.content.Intent;importandroid.util.Log;{//重寫onReceive方法@OverridepublicvoidonReceive(Contextcontext,Intentintent){//後邊的XXX.class就是要啟動的服務Intentservice=newIntent(context,XXXclass);context.startService(service);Log.v("TAG","開機自動服務自動啟動..");//啟動應用，參數為需要自動啟動的應用的包名Intentintent=getPackageManager().getLaunchIntentForPackage(packageName);context.startActivity(intent);}}第二步：配置xml文件，在receiver接收這種添加intent-filter配置[代碼]java代碼：第三步：添加許可權如何實現一個不會被殺死的進程看Android的文檔知道，當進程長期不活動，或系統需要資源時，會自動清理門戶，殺死一些Service，和不可見的Activity等所在的進程。但是如果某個進程不想被殺死（如數據緩存進程，或狀態監控進程，或遠程服務進程），應該怎麼做，才能使進程不被殺死。addandroid:persistent="true".xml切記，這個不可濫用，系統中用這個的service，app一多，整個系統就完蛋了。目前系統中有phone等非常有限的，必須一直活著的應用在試用。提升service優先順序的方法Android系統對於內存管理有自己的一套方法，為了保障系統有序穩定的運信，系統內部會自動分配，控製程序的內存使用。當系統覺得當前的資源非常有限的時候，為了保證一些優先順序高的程序能運行，就會殺掉一些他認為不重要的程序或者服務來釋放內存。這樣就能保證真正對用戶有用的程序仍然再運行。如果你的Service碰上了這種情況，多半會先被殺掉。但如果你增加Service的優先順序就能讓他多留一會，我們可以用setForeground(true)來設置Service的優先順序。為什麼是foreground?默認啟動的Service是被標記為background，當前運行的Activity一般被標記為foreground，也就是說你給Service設置了foreground那麼他就和正在運行的Activity類似優先順序得到了一定的提高。當讓這並不能保證你得Service永遠不被殺掉，只是提高了他的優先順序。從Android1.5開始，一個已啟動的service可以調用startForeground(int,Notification)將service置為foreground狀態，調用stopForeground(boolean)將service置為background狀態。我們會在調用startForeground(int,Notification)傳入參數notification，它會在狀態欄里顯示正在進行的foregroundservice。backgroundservice不會在狀態欄里顯示。在Android1.0中，將一個service置為foreground狀態：setForeground(true);mNM.notify(id,notification);將一個service置為background狀態：mNM.cancel(id);setForeground(false);對比看出，在1.0API中調用setForeground(boolean)只是簡單的改變service的狀態，用戶不會有任何覺察。新API中強制將notification和改變service狀態的動作綁定起來，foregroundservice會在狀態欄顯示，而backgroundservice不會。Remoteservicecontroller&binding跨進程調用Service。暫時不研究。如何防止Android應用中的Service被系統回收?很多朋友都在問，如何防止Android應用中的Service被系統回收？下面簡單解答一下。對於Service被系統回收，一般做法是通過提高優先順序可以解決，在AndroidManifest.xml文件中對於intent-filter可以通過android:priority="1000"這個屬性設置最高優先順序，1000是最高值，如果數字越小則優先順序越低，同時實用於廣播，推薦大家如果你的應用很重要，可以考慮通過系統常用intentaction來觸發。

『柒』 如何讓自己的Android程序永不被系統kill

1、使用AlarmManager，定時給自己廣播。
2、alarmMgr.set(AlarmManager.RTC_WAKEUP, l, pendIntent)，就算被殺了、手機待機了，還是可以啟動起來。
3、監聽網路狀態。

『捌』 請問android APP 如何防止被系統殺死和用戶卸載

這個有點流氓軟體的味道了……

如果是防止被殺，參照一下這里吧（Android開發之如何保證Service不被殺掉）

如果要防止用戶卸載，可以用輔助功能監聽用戶是否點開了軟體卸載頁面，如果點開了，查找頁面文字或ID，檢測一下是不是你的軟體，如果是就點取消。但是需要引導用戶把輔助功能打開。

建議不要這么做，防止被殺可以，但是防止卸載如果被舉報會招到官司的。